Kernel auditing
Craig Dooley
craig at xlnx-x.net
Tue May 18 15:27:51 PDT 2004
On Tue, May 18, 2004 at 10:40:33AM -0700, Matthew Dillon wrote:
> First, a userland utility similar to jail, called 'audit', which
> passes a logging file descriptor into the kernel and installs an
> audit control structure in a process. This control structure would
> be (nominally) inherited by any forked children, and the process would
> be able to have a chain of them so multiple audits could be performed
> on the same process.
>
> This userland utility would work like 'ktrace -i' or 'jail'. You would
> be able to say:
>
> audit -f /var/audit/sshd.audit -i sshd # run sshd and audit
> # everything it or anything
> # it forks ever does.
>
> audit -f /var/audit/jail1.audit -i jail ....
>
I like this idea, and this would keep the log file size down. It does
take away from the ability to backtrack the process tree all the way to
init and grab information such as uid/gid from moving back. Maybe I
should change it so the initial program gets all it's state put into the
beginning of the audit, so you will still know what uid any children of
say sshd are running as.
> Users operating within the audit would be able to run their own
> audits in addition to the one you might be running on them.
>
> struct proc {
> struct audit_link *p_audits;
> }
>
> struct audit_link {
> struct audit_link *a_next;
> struct audit *a_audit;
> }
>
> struct audit {
> ... audit control structure ...
> struct file *ac_fp; /* logging file pointer */
> }
>
> --
>
> Second, the audit functions should tap into the system calls *after*
> their arguments have been moved into userspace. A lot of hard work has
> been done to separate the userland and kernelland portions of the
> system calls and we definitely do not want the audit functions doing
> copyin()'s or anythign like that.
This works very well for say exec, but open, and access, which just use
namei and never look at the name don't give me much to work with. I
agree that doing to copyin()'s is not the cleanest way, but I didn't
want to change the API of namei to tell it what kind of operation to log
since I'm assuming most calls to namei won't be logging anything.
>
> In fact, I feel that this is extremely important for the abstraction...
> if a particular system call is not sufficiently separated to be able to
> call the audit functions with only kernelspace objects, then we need to
> fix that system call. It's a lot of work to change this later on, now
> is the right time.
>
> I think these two things would actually be very easy for you to implement,
> and it also solves the 'wheretolog' problem. You could pass a
> connected TCP socket or a UDP socket to log outside the box, for example,
> or you could pass one side of a pipe if you want a process to process
> the audit as it occurs.
Yes, adding the audit command and passing it's open file descriptor
would make it much cleaner. Would this require a new system call to
attach an audit log to an fd? And then would I use VOP_WRITE to write
out to the fd from kernelside? I was thinking caps would have been
good, but moving to this per process model would make sorting the data
much cleaner. It also very easily facilitates the idea of auditing a
jail from the actual host. Thanks for the input, and I'll start banging
away at some of these ideas.
-Craig
>
> Once these initial core things are done, the feature could be committed
> and then you and others (I'm sure there are others who would love to work
> on this) could add additional features, cleanups, and so forth.
>
> -Matt
>
> :If anybody is interested, here is the code I've been working on. It
> :implements kernel auditing for a couple events, but the framework is
> :there. Theres still a couple things I might want to change including
> :
> :- Move all buffer management into one thread. Writing an event would be
> :sending the event to this thread, and the output would send read events
> :to this thread. This will let it run lockless (and also without per-cpu
> :buffers, which aren't bad, but to get that working i think there would
> :need to be a device for each cpu to remove the token)
> :
> :- Move the output over to CAPS instead of a character device.
> :
> :- Audit many more event types, and add support for user programs to send
> :audit events, much like Solaris BSM (su, login, other priveleged
> :programs)
> :
> :- Implement a facility like /dev/auditctl that would allow at a
> :per-event level specifying what to log and what not to.
> :
> :- User tools. I want the ability to broadcast over a network, have
> :secure logging outside a jail, and I think XML output (plain text would be
> :nice, but I dont want to write the tools to do queries like "find
> :processed forked from pid X with userid =3D 0 that used exec").
> :
> :For now it's been running for about a week with no problems. It can get
> :pretty large log files, but they will compress with gzip about 5x. To
> :use, apply the patch. mknod c 7 1 /dev/audit. cat /dev/audit >
> :auditlog. I want to finish up the event types defined in Posix 1003.1e
> :before I start doing re-architecturing, but if anybody wants to send me
> :any suggestions or bugs, please do since this is my first major
> :piece of kernel code. Thanks
> :
> :-Craig
> :--=20
> :------------------------------------------------------------------------
> :Craig Dooley craig at xxxxxxxxxx
> :------------------------------------------------------------------------
--
------------------------------------------------------------------------
Craig Dooley craig at xxxxxxxxxx
------------------------------------------------------------------------
Attachment:
pgp00005.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00005.pgp
Type: application/octet-stream
Size: 187 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/submit/attachments/20040518/14018c60/attachment-0019.obj>
More information about the Submit
mailing list