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

Re: [RFC][PATCH] (#2) Prelim in-kernel file system auditing support

On Thu, 27 Jan 2005 00:19:29 CST, "Timothy R. Chavez" said:

> So then, in theory, when I do a "cat /etc/passwd" and both "etc/" and
> "passwd" are being watched and the open syscall() will generate an
> audit record, I should see a record for both file system objects in
> the audit log.  For the open syscall(), there should be a message for
> "etc" and "passwd", right?  Because if I hit the permission() for
> "etc" and "passwd" I should be adding both "etc" and "passwd" to the
> audit context for the open() because they are both being watched.  I
> was only getting a record for "passwd"

Take care that you don't indiscriminately add entries for /etc to the audit
context for files you don't care about.  If you have a /etc/we_dont_care,
you may fill up your audit trail for lots of bogus traces of /etc.

For that matter, so much stuff opens /etc/passwd in R/O mode (like every single
program that uses getpwent()) that auditing it is probably a Bad Idea on most
systems (unless it's an embedded box where you've hunted down all the getpwent()
callers already ;)  So you need to make sure that your code doesn't attach
the /etc message unless the next path component is "passwd" *and* it's something
other than R/O.  Unfortunately, permission() really only has access to *this*
component of the pathname, so what you may have to do is just save a bit somewhere
saying "we went through /etc", and actually attach it when you're looking at
the next component and decide it's something hinky enough to require an audit

(If this stuff was easy, we'd have done it a decade ago.. ;)

Attachment: pgp00008.pgp
Description: PGP signature

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