[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: auditd design decision

On Sat, 8 Jan 2005 10:53:05 -0800 (PST), Casey Schaufler
<casey schaufler-ca com> wrote:
> --- "Timothy R. Chavez" <chavezt gmail com> wrote:
> > Hello,
> >
> > But last night in a dream,
> > a giant donut told
> > me that I should just create a file, watch.list,
> > which auditd will
> > read when its started and insert any/all new watches
> > into the
> > filesystem.
> Donuts are notoriusly one-dimensional in their
> approach to problems like this. The notion is
> simple and attractive, but ...
> If /etc/passwd is (hard) linked as /tmp/mojo
> accesses to the file may be missed. Your scheme
> is monitoring the file system name space, not the
> file system objects. This is is a close
> approximation of what you need, but not sufficient.

Oh, Casey.  I guess I should have provided more context to what I was
actually doing.  We're already aware of the problem you've just
described and I've been working on both the userspace and kernel
implementation of a solution.  Hopefully by the end of next week (I'm
going to be in an SELinux class for 3 days) I'll have out to this
list, the kernel code that compliments the userspace code I was
speaking of (although there is a good chance I'll be unable to release
the userspace code until IBM is approved to do such things).

The userspace interface into the kernel's audit subsystem simple
provides a path ending with the filename/directory we wish to audit (I
don't believe we're dealing with devices (at least not yet)).  Insert
<some kernel magic here> and the inode of the file/dir we wish to
watch and its parent's inode have all the necessary information. 
You'll see the patch.

> > This way, when we mount over /etc, and
> > we're watching
> > /etc/passwd, then when we restart auditd, /etc it
> > will insert a watch
> > for /etc/passwd on the new device.
> Which is correct from a namespace view but wrong
> from a object view.
> > We do it this
> > way so we minimize
> > our impact on kernel code (not sure we want to go
> > screwing around with
> > mount())
> The impact should be in the real right place,
> and no sneaking about.

What's better for an upstream solution?  Obstrusive hooks in core VFS
functions or the inconvience of the admin having to restart auditd (or
I guess, reload the watch list from auditctl)?  Klaus might be able to
make this call.  So far we've been fairly quiet on what we really want
to do with mounting.  I'm pretty sure mount --binds are taking care of
with the current implementation (that I'm working on).  I'm not sure
we want the audit subsystem to be dynamic like this and adapt to such
changes.. it could add some unappealing complexity.

> > This might be a little cumbersome to do
> > when we wish to
> > remove watch points, because in theory, we'd want to
> > detect the
> > absence of /etc/passwd on a restart to know that we
> > must remove its
> > watch point from the file system.  Does this sound
> > reasonable or do we
> > need a greater degree of flexibility with the
> > ability to insert/remove
> > watch points without restarting auditd like we do
> > with rules?
> To meet CAPP and LSPP requirements you need to
> address both file system name space and file
> system object audit issues.
>     # mv /etc/passwd /tmp/foo
>     # touch /etc/passwd
>     # analyse /tmp/foo
> The object that was named /etc/passwd has been
> "analyse"d, and if you care about the object
> or the data it contained, you should be able to
> find that in the audit trail. It is also
> interesting that the current object located in
> the name space at /etc/passwd was created by
> touch. Name space alone does not tell the whole
> story.

As far as "movement" outside of a watched location, we're not going to
audit.  If we're only interested in /etc/passwd and we move
/etc/passwd to /tmp/passwd (we're presumably the administrator),
/etc/passwd no longer exists and we will not receive records for any
accesses on /tmp/passwd (unless /tmp/passwd is a watched location
(object) itself).  When /etc/passwd exists again or the inode
associated with /etc/passwd still exists, generating audit records for
/etc/passwd is still possible.

When creating a hard link to /etc/passwd from /home/user/bypass,
you're right, we don't want a bypass of the audit subsystem.  Because
our information is associated with the inode, however, and we can't
hard link across devices, we still get audit records.

For other cases, to know if a file/dir is being watched, it consults
its parent (two hooks in dcache).  If its parent's i_audit field is
NULL, its watchlist is empty (depending on how I decide to handle
removal of watches), or the file/dir is not in the watchlist, we're
not being watched, otherwise we are, and we point ourselves at our
watch entry in the watchlist.

When we hit permission() in fs/namei, if we are not NULL, we're being
watched and we add ourselves into the audit_context of the current
task via a hook.  If the current task has a rule stating interest in
what file system objects its accessing, it will generate logs for them
upon exit.  All other filtering, if any, of file system objects will
be handled in userspace.  Matching syscall with file system object can
be done with serial numbers.

> Now, was it a jelly donut, or a Krispy Kreme?
Neither.  It was a crappy Maple glazed donut from H.E.B (a regional
grocery story here in Texas)

I think it'd be easy for the time being to insert watch points at
auditd start up and remove watch points at auditd shut down.  Or if
you prefer not to add code to auditd, we can do something like:

Insert watch points:
./auditctl -W watch.list

Remove watch points:
./auditctl -w watch.list

> =====
> Casey Schaufler
> casey schaufler-ca com
> __________________________________
> Do you Yahoo!?
> The all-new My Yahoo! - What will yours do?
> http://my.yahoo.com

- Timothy R. Chavez

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]