Re: Kernel auditing

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    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 ....

    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.

    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.

    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@xxxxxxxxxx
:------------------------------------------------------------------------