Messages in this thread | | | Date | Fri, 9 Apr 1999 06:30:47 +0200 | From | Olaf Dabrunz auf bilbo <> | Subject | Auditing? |
| |
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/
| |