RE: audit 0.6 release
--- Leigh Purdie <Leigh.Purdie(a)intersectalliance.com>
wrote:
But that raises the question I guess.. If a user
attempts to
access /path/to/protected/file.txt, and ACLs block
them at /path/to,
what should the event report?
In existing (Solaris, Irix) audit systems you
will get
- The access attempted (e.g. open for read, stat)
- The process attributes
- The path requested, /path/to/protected/file.txt
- The path resolved, /path/to
- The attributes of /path/to that resulted in
access being denied (the ACL in this case)
It is amazingly common that the path requested
is not the path that ends up being interesting
in audit records.
Failed access
to /path/to/protected/file.txt (at which point, the
auditor wants to
know 'how did they get that far in the directory
tree??), or Failed
access to /path/to (at which point, the auditor has
no idea of an
attempted attack on a 'sensitive file')?
This is why both are necessary.
My feeling is that the second option is most useful,
but if we follow
the above logic to conclusion, perhaps we would
receive both events.
Meeting the CAPP requirements as well as being
useful to an auditor adds a certain spice to the
design.
> - When /etc/passwd is renamed to /etc/opasswd
> do you want to stop watching it?
Yes. I don't think we should second-guess the intent
of the auditor. If
they request /etc/passwd, monitor that only. If they
request /etc/*passwd*, that's a different story.
The CAPP requirements are written in subject/object
terms. The object that was /etc/passwd is now named
/etc/opasswd. To meet the CAPP requirements you need
a way to monitor the object, even if the name
changes.
Pathnames aren't even attached to the objects.
A file can exist without one, and still needs to
be audited even when there is no reference to it
in the file system namespace. Really.
=====
Casey Schaufler
casey(a)schaufler-ca.com
__________________________________
Do you Yahoo!?
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250