Re: Kernel auditing

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

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

    Well, like ktrace, the output from multiple processes will wind up in
    the same audit file, so each audit record would need some sort of
    identifier (like a pid).

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

    Well, namei() just copyinstr()'s the data anyway.  Arguably it makes
    more sense for NDINIT to do this and for NDFREE to release the data
    rather then for namei() to do this, but that would require significant
    programming.  I can look into it next week (I'm not going to be here this
    weekend).

: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
:Craig Dooley                                            craig@xxxxxxxxxx

    Yes, similar to ktrace.  You would not use VOP_WRITE, necessarily... well,
    you would, but it would probably be better to create a kernel thread
    for each audit and then buffer the data, waking up the thread only when
    necessary (and the thread would flush the pending data once a second
    anyway).  That way the system would be able to run at nearly full speed
    *even* if you are auditing every single process.

    Creating a kernel thread is *very* easy.

    The system call would route the request to the thread governing the
    audit structure.  e.g. 'add this process to the audit' or 'remove that
    process' or 'close out the audit' or 'change the audit descriptor', etc.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>