lkml.org 
[lkml]   [1999]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectAuditing?
Hello.

I just decided to go ahead and post my questions and thoughts without
completely researching this topic. Sorry if some of the ideas are presented
with many details already. I guess I'm still too much of a cathedral builder,
alas it just takes too long. So I'm writing everything down now (before I
forget all of these thoughts anyway). Please *use* them in *any way* you might
find appropriate. Hope someone finds this helpful. (I will see how much I can
contribute after this. Too many aims, too many thoughts, too little time.)

I have looked around a bit, but couldn't find anything about auditing support
in the kernel. Is there any auditing patch for the kernel? Is anyone working
on auditing support at the moment? Are there plans, thoughts or discussions?
Can someone please provide pointers?

If none of the answers is yes, I would be interested to know what people think
about providing auditing facilities in the kernel. IMO, auditing in the kernel
is a neccesity for one reason:

- It supplements the features needed for a secure OS. This is just one
feature of several that are still missing, though, like ACLs.

For another reason, configurable and flexible auditing (with regard to the
log destination) is quite desireable:

- It provides for additional debugging facilities, i.e. facilities that
are useful for system-wide debugging and administration. Look at utilities
such as lsof and fuser to understand what I mean.

Auditing facilities may come in handy in other areas as well. (The following
section became quite lengthy, but I kind of felt I needed to illustrate some
other possibilites and innovations a more generalized form of auditing might
make possible. I do not neccesarily mean to support the following ideas, but I
would like to mention them to cause more people to become interested in
auditing):

- It provides a facility that triggers program actions in response to certain
user activity, such as a file being written, opened or closed. Examples of
actions that could be triggered are:
- Updating backups of files that have a "watch" set on them, triggered by
closing the file. This would save the changes that are made between the
normal backups, which is sometimes desireable on crucial files.
Moreover, on huge and enormous file systems (which Linux installations
don't have yet, but which may be coming in the future) the usual backup
procedures can be quite time and bandwidth consuming. Creating backups
on an as-needed basis and distributed over time may be a or even the
solution for this problem.
In more usual installations having the user specify some of his own
files for immediate backup would help. (This could be implemented by a
priviledged demon that is notified by the kernel when a file is closed.
It can configure "watches" in the kernel and does so on user request.
The demon would look up a user's permissions and limits in its
configuration, to prevent abuse.)
- File operations on files in a CVS repository (or somesuch) can trigger
an appropriate action of the CVS program, such as a notification to a
group of developers working on a module. This would help establishing a
complete changelog and information flow by having the kernel enforce it.
Several policies are possible then, the most interesting of which would
promise not to lose information about who did when what to the
repository. (I.e. the policy rules set up in the repository keeper
program (CVS in this example) could not be bypassed by using direct
filesystem commands to access files in it. This enables policy
*enforcement* for any policy, be it a fascist, permissive or a moderate
policy.)
- Several other uses like the above are possible. Basically all
applications that need information about system-wide events (as opposed
to process-specific or even user-specific events) can be implemented
without resorting to polling. Of course, the audit facilities must
be solely under superuser control and also must only be delivered to
priviledged interfaces. The above models use priviledged programs which
can then disseminate selected information to user programs. A lot of
care must be put into the design and implementation of such programs, as
they are dangerous. The danger is mainly that they may provide
(un-)covered channel information to user programs, and that a user may
instruct the demon to modify or copy data that can not usually be
accessed by this user.

As a starting point, I would go on to define an auditing architecture. The
first step is clarifying the following points:

- What should be audited?
- What interfaces are needed?
- Where is the best place to add auditing?
- What about the future?
- In summary: what problems are we trying to solve?
- And: what additional dangers do we create?

The problem I would like most to see solved is to provide the auditing
capabilities that are traditionally demanded for "secure" OSes, as in TCSECs
security classes (C2 to A1, that is). This would help using Linux in secure
environments and also bring Linux closer to acquire some security
certification, which will influence industry and customer opinion about the
OS.

Some of the answers can be the following (adapted from TCSEC (DoD 5200.28-STD,
which can be found on the web, or see Russell, Gangemi: Computer Security
Basics, O'Reilly 1991)):

What should be audited?
The standard answers seem to be:
- Logon/logoff (remote or local)
- File system activity: open, close, create, delete (unlink), rename,
mkdir, ...
- Security priviledge/attribute change: chmod, chown, setuid and friends
- probably also: Covert channel audit: proc filesystem (system load, idle
time, disk space usage...)
- probably also: statistical information about user and program behaviour,
such as typing patterns, typing errors and other kinds of activity
pattern statistics; this is useful information for intrusion detection
systems
These would fit most of the requirements of TCSEC, but there are others that
are interesting enough and also might be required by some other
certification (Red Book, CC requirements etc.). These more obvious of them
are:
- SySV IPC activity: shm*, msg*, sem* functions
- Network activity: socket, accept, connect, sendmsg, sendto, revmsg,
recvfrom, ...
- highly risky system calls (x86 Linux): iopl, ioperm, modify_ldt, vm86
- Resource locking activity: lock, flock, fcntl, mlock, mlockall
For system-wide debugging it may be desirable to select any subset of the
system calls to be traced to a different facility (syslog DEBUG facility,
/proc/audit/* or somesuch). This will be especially helpful in multithreading
and multiprocessing debugging, since events are logged globally in the
correct order. Some additional event sources for debugging come to mind:
- reception of signals: it should be possible to find out when a signal is
received by a process
- process termination: maybe the termination of a process should generate
an audit event, since the reception of the SIGCHILD signal can be
delayed by the parent process; the reason for termination should be
logged
It should be possible (and is in part demanded by TCSEC and others) to
be more selective with audit sources. At least, it should be possible to
constrain auditing to a certain user, group or specified group of users.
When Linux provides security levels (as is presumably with the RSBAC patches
by Amon Ott), auditing should be constrainable by level, too (cf. TCSEC).
But in the same vein as above, I would rather make the constraints
configurable for most or all of the information that relates to an event.
This would include these selection criteria:
- time constraints: e.g. "in the next ten minutes"
- initiator: UID and/or level of the program
- success or failure
- origin: e.g. "from programs attached to terminal pty3", "from programs
without terminals attached"
- name of object: filename, port number, network address, IPC ID,...
- object security level: e.g. "TOP SECRET"
Also, it should be possible to select any of this (and other) related
information for inclusion in the log output.

Following TCSEC again, filtering events according to these selection
criteria should be supported in the kernel. But userspace programs have to
be available for this as well. Here the Unix standard utilities such as
grep, sed, awk, perl and also logsurfer are good candidates. We only have to
make sure the audit log format has a standard form with easily parseable
fields.

What interfaces are needed?
- Obviously, we need an interface to move audit information from the kernel to
userspace.
- A second interface is needed to control the selection of information (the
setting of the event filter).
- A third interface is what I call the privacy interface: it allows a user to
learn which subjects (programs) and objects that belong to him or that he
interfaces with are audited by whom (which PID) in what way (the filter
setup). It is mandatory that a user can only find out information that
concerns him directly. This can be further constrained by the following
facility.
- The fourth interface is the policy interface: it allows the superuser (or
someone with special capabilities) to define a system policy. It also allows
a normal user to look at the system policy.
The policy defines the following items:
- what settings are permissible for event filters (i.e. what events may be
audited in what way)
- what information may a normal user learn about the auditing activity that
directly concerns him.


- The output interface is most obviously the kernel logging interface, i.e.
both syslog(2) and /proc/kmsg. But it should be possible to have more than
one program select its events and have the information sent to a separate
interface. This could either be a dynamic device as for /dev/pts (and
/dev/ptm), or a dynamic /proc file, such as /proc/audit/amsg1 (amsg2,...,
amsg11,..., amsg101,...).

- Configuration of event filters and output channels should be done either via
one file in /proc, such as /proc/audit/config, which then multiplexes
through all attached filters via the PID, or via the following scheme:
- /proc/audit/config is used to
- configure the event sources and the filter for /proc/kmsg and syslog(2)
- request creation of additional audit files in /proc/audit/, returning
the name of the created file
- the output to all files /proc/audit/amsg* is organized in ring buffers,
as for /proc/kmsg
- a process uses the newly created /proc/audit/amsg* as follows:
- open it
- configure the event sources and selection filter for *this* amsg file
(this allocates the resources: ring buffer, config info and filter)
- repeatedly do select() and read() on the amsg file
- maybe reconfigure "the file" in between reads
- close it: this destroys the file and its resources (buffer, filter,...)
- an amsg file must be opened and closed to make it disappear (which makes
this operation trivial)
- there should be an open timeout: after the creation of the amsg file, if
the file is not opened before the specified timeout (can be a creation
parameter with a maximum of 1 hour or so, a default of maybe 1-5 minutes),
the file is destroyed.
(maybe there are still better schemes to control the lifetime of the file)
- there should be a maximum number of amsg files that can be created,
such as 1024 (remember though, that an amsg file only uses up a
significant amount of resources after it has been opened and configured;
when the process that opened it dies prematurely, the file is closed
gracefully. Thus, amsg files can only consume resources as long as a
program uses them.)
- configuration errors let the write() return an error, and the error
message (and number) can be read from the amsg file

- The privacy interface can be a file like /proc/audit/privacy, that returns
information about the currently active auditing settings for subjects and
ojects belonging to the UID of the reading process. It might also return
auditing information about subjects/objects this UID interfaces with,
depending on the policy

- The policy interface is used to set the policy when the UID of the writing
process is 0. It is used to read the policy when it is being read from, with
any UID.


Where is the best place to add auditing?
The only place to generate this kind of auditing information is at the
source, in the kernel. The ptrace() facility only provides per-process
auditing. Also, some of the auditing information is not available at the
kernel interface level, most notably covert channel information and some
kinds of user and program behaviour statistics that may be useful for
intrusion detection systems.

The kernel should be providing event selection and filtering facilities as
well, since selection prevents unwanted events from being generated and
filtering prevents unwanted events from being propagated, which saves
resources best when done as early as possible.


What about the future?
The future might bring extensions, changes and even complete rewrites of a
to-be-written audit subsystem (as always). Thus it should be written as one
or a few modules that do the work (such as filter.c, select.c, generate.c
and statistics.c, interfaces in config.c, privacy.c and policy.c) and some
hooks should be inserted below each system call in the kernel and in the
keyboard driver as well as in some other places (the network layer?) that
call something like do_generate() and do_stats(), if a simple test reveals
to them that they should do this. (The test can be something like

if (aud_select & AUD_OPEN)
do_generate(...);

)

This should make changes bearable.

Since the present is still to be talked about and implemented, I refrain
from thinking further into the future now. (I.e. I have said all I could
think of and need to have a break now :)

In summary: what problems are we trying to solve?

1. Make Linux systems more applicable in secure environments.
2. Improve debugging facilities for Linux, especially global, multithreading
and SMP debugging.
3. Maybe provide a generic interface for global events that trigger globally
important actions.

What additional dangers do we create?

Attackers may gain additional information through holes in new kernel
facilities. They may even convince a priviledged demon to do nasty things when
they find holes in the design or in the implementation.

Jup, that's it. I'm going to release this little monster of thought to you
now. Let's see what happens... :-)

Enjoy.

Olaf

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.876 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site