RE: audit 0.6 release
Casey Schaufler wrote:
> > Ideally, access to an
> symlink will actually
> > generate TWO events - one for the symlink (open -
> read), one for the
> > final file (open - as per user requirement).
Erg. That logic implies that you'd want a record
for each directory the lookup passes through.
Don't think that that has never been seriously
considered, BTW.
From a security auditor's perspective, they're rarely
interested in
directories - so recording such access may not be spectacularly
interesting to the person reviewing the logs (however, it might be VERY
interesting to a HIDS system that is watching the logs). But I guess
similar consequences would result from a symlink to a symlink to a
symlink [ .. ] .. to a file - so I see what you mean.
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? 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')?
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.
> That's a meaningful statement for symlinks but not
> for hard links. With
> hard links there is no one 'final path name';
> they're all just different
> names for the same inode. If I hard-link /etc/passwd
> to /tmp/fish then
> both of those are _real_ names for it.
That is correct. In this case what you want to
do is
- Get the pathname of the object you want
to filter on (/etc/passwd)
- Fetch the dev/inode information
- For each record that comes out look
for either the name you requested or
the dev/inode pair.
- When you see the pathname unlinked you
might forget the dev/inode, but since
when it was /etc/passwd you cared about
it who's to say you don't now, just
because it has a different name?
- 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.
This could go either way.
- When you see the pathname created you
refetch the dev/inode
> It would be almost impossible to implement a system
> which is asked to
> log 'all access to /etc/*' and includes in that the
> access to /tmp/fish.
Costly, yes.
=====
Casey Schaufler
casey(a)schaufler-ca.com
--
Leigh Purdie, Director - InterSect Alliance Pty Ltd
http://www.intersectalliance.com/