audit 0.6 release

[Leigh Purdie]

> 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)

Although this is what I'd LIKE solaris to provide me, unfortunately, it
doesn't actually provide the requested path (except in an earlier 'exec'
event associated with the command in question, but this is not
spectacularly useful):

comet   SolarisBSM      1       header,144,2,execve(2),,Fri Jan 14
11:18:01 EST 2005, + 887 msec        path,/usr/bin/cat
attribute,100555,root,bin,26738688,296,0
exec_args,2,cat,/home/george/test.txt
subject,-2,red,other,red,other,467,0,0 0 0.0.0.0        return,success,0
sequence,1523   snareseq,1524

comet   SolarisBSM      1       header,84,2,open(2) - read,fe,Fri Jan 14
11:18:01 EST 2005, + 895 msec  path,/home/george
subject,-2,red,other,red,other,467,0,0 0 0.0.0.0        return,failure:
No such file or directory,-1    sequence,1529   snareseq,1530

However, solaris will provide the 'requested path' if you can access the
directory, but the file does not actually exist (eg:)

comet     SolarisBSM      1       header,89,2,open(2) - read,fe,Fri Jul
23 16:07:58 GMT 2004, + 547 msec  path,/var/ld/ld.config
subject,red,red,other,red,other,1370,1339,2849 5888 10.0.0.1
return,failure: No such file or directory,-1    sequence,13


> Meeting the CAPP requirements as well as being
> useful to an auditor adds a certain spice to the
> design.

*laugh* What an amazingly graceful way of implying that CAPP and real-
world user requirements are not always perfectly aligned. Very true. ;)


> > >     - 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.

See above comment ;)
I don't personally have a problem with a subject/object approach, but I
think that a level of wildcard audit filtering is a critical
precondition for a successful (and effective!) audit implementation.

This could conceivably be done is through object inheritance on
directories (like Windows - c:\path\to\secretstuff\*), or through path-
name filtering in the kernel. However, the windows approach can limit
the flexibility of the auditor somewhat. I've mentioned examples before,
but a good real-world one is the 'No foreign nationals' category of
intelligence material (lets call the directory 'NOFRN'), but it could
apply equally to budget/financial data, human resources information, or
any other info that is sensitive, but distributed (and controlled by)
many departments within an organisation.

With a wildcard-based rule system, a security auditor can put a rule in
place like match=.*/NOFRN/.*, and tell departments that auditing is
available for their NOFRN data - all they need to do is place it in a
'NOFRN' subdirectory with their directory structure.

With a object-inheritance structure, you'd either have to explicitly
establish a rule for each new NOFRN directory, or modify your directory
structure (and perhaps user practises somewhat) to accommodate auditing
(which may not be a bad things in many circumstances).

Neither approach is bad - but since we're still at the decision-making
point from a filtering perspective, I thought I'd highlight some
potential repercussions. :)

Regards,

Leigh.

> 
> 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 at schaufler-ca.com
> 
> 
> 		
> __________________________________ 
> Do you Yahoo!? 
> Yahoo! Mail - now with 250MB free storage. Learn more.
> http://info.mail.yahoo.com/mail_250
> 
> --
> Linux-audit mailing list
> Linux-audit at redhat.com
> http://www.redhat.com/mailman/listinfo/linux-audit
-- 
Leigh Purdie, Director - InterSect Alliance Pty Ltd
http://www.intersectalliance.com/