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
record....
(If this stuff was easy, we'd have done it a decade ago.. ;)
Attachments:
- attachment.sig (application/pgp-signature — 226 bytes)