Re: Kernel auditing
: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@xlnx-x.net
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@backplane.com>
討論串 (同標題文章)