audit 0.6 release

[Leigh Purdie]

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 at schaufler-ca.com

-- 
Leigh Purdie, Director - InterSect Alliance Pty Ltd
http://www.intersectalliance.com/