audit 0.6 release

[Leigh Purdie]

This issue takes us back to the discussions around VFS auditing
(https://www.redhat.com/archives/linux-audit/2004-
December/msg00002.html) - in which was highlighted the need to audit
files that either:

* Do not currently exist / have an inode
  - eg: "Tell me whenever someone attempts to view a file
called /etc/hosts.equiv, despite the fact that the file does not exist
at the moment."

* Match file/directory creation against a particular wildcard,
regardless of whether they currently exist or not
  - eg: "Tell me whenever a file is created in a directory with the word
'SECRET' as part of the directory name, or
  - "Tell me whenever someone creates a file called '.rhosts' somewhere
under the top directory '/home/*/'.

Tagging an inode with an audit flag is a good starting point to gain a
capability, but I think we need to find a more comprehensive solution to
provide an effective auditing subsystem that meets the 'filtering'
requirements of many organisations.. even if it's something like:
  * If inode exists for file, get real path, and filter on that basis.
  * else, realpath() the vfs_root, plus the argument supplied by the
user in open() (note: there's a potential for race conditions here
though).
.. So 'cat /home/../etc/cron.daily/../hosts.equiv' : no such file or
directory is reported as a failed access to /etc/hosts.equiv.

Also, w.r.t the success flag, we've encountered situations where a user
wants to filter on both:
* A broad success/failure, and
* specific return/error codes

Most auditors just want to know whether the system call worked, or not
(ie: did they run the command, or didn't they.. did they open the file,
or not).
Others, however, are particularly interested in particular return/error
codes, and want to filter on that basis (eg: ignore logs relating to
ENOEXEC's in execve attempts).

I'm not suggesting adding in such filtering requirements specifically
for particular system calls.. but providing both a 'indicative success
value', and a 'specific return code' in each audit event is probably a
good move. That way, an auditor doesn't have to 'man 2 open' or 'man
every time they need to work out whether '-1', '0', or 'a non-zero
positive value' actually indicates a 'success' for a particular system
call.

A good example of this might be execve. You should probably return both:
* TRUE or FALSE (whether the command failed), and
* The resulting return (for success) or error (for failure) code - eg:
EACCES, EPERM, or ENOEXEC.

This addition will certainly make filtering easier, and reduce the
eventual volume of audit log information that needs to be reviewed by
the security administrator.

Regards,

Leigh.

On Thu, 2005-01-06 at 18:19 -0500, Steve Grubb wrote:
> On Thursday 06 January 2005 17:40, Steve Grubb wrote:
> > assuming user x is uid 501
> > auditctl -a entry always -S unlink -F uid=501 arg0=file
> 
> This doesn't work. a0 doesn't take strings. you can lookup the inode for the 
> file (if it doesn't change much). Should be something more like this:
> 
> auditctl -a entry,always -S unlink -F uid=501 -F success!=0 -F inode=12345
> 
> But the success flag just doesn't seem to be working right, either...
> 
> -Steve Grubb
> 
> --
> 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/