Re: best way to audit in vfs
On Tue, Dec 14, 2004 at 04:06:08PM -0500, Stephen Smalley wrote:
On Tue, 2004-12-14 at 15:50, Serge E. Hallyn wrote:
> Why can't you store the info in the current->audit record until syscall
> exit, and only send a message to userspace if the syscall exit says to
> do so?
Another point to keep in mind is that you ultimately want to instrument
other subsystems in the same manner as the filesystem code to capture
relevant information copied by the kernel from userspace pointers (e.g.
socket addresses), and I doubt you want to keep adding all of this
object identification information into the current audit context (and
there can be mixing, e.g Unix domain socket interplay with the
filesystem, so you might need object identification information for
multiple kinds of objects on a single syscall).
I think this is the fundamental disagreement here - if you want to filter
audit records based on object identity, you need to have the object
identity information available when applying the filter rules. If you
want to do the filtering in the kernel, there isn't really any
alternative to storing this information in kernel space.
Note that I don't think that very much additional information will be
needed - the only real identity crisis identified so far (from a CAPP
perspective) have been the filesystem objects, due to the hardlink/path
issues. SYSV IPC objects each have unique identifiers available directly
in the register syscall argument with no confusion.
Socket addresses were mentioned as being useful additional information to
include in the relevant audit records and it's only available through the
userspace pointer, but I don't think anyone was proposing kernel side
filtering based on them. Keeping with the lightweight approach, I think
only the minimal amount of information should be collected that is
security relevant. I don't think the audit system is intended to be a
full-featured debugging system that can audit everything happening in a
syscall.
I think the linked-list approach mentioned may be appropriate, keeping
only the information needed for in-kernel filter decisions in directly
accessible arguments. Any other audit information could be stored in the
list and then delivered to userspace in bulk on syscall exit.
-Klaus