Auditing - Snare, LAuS, SELinux

[James Morris]

On Wed, 8 Sep 2004, Stephen Smalley wrote:

> > Similarly, implementing a policy of 'audit all attempts to write to files
> > in /bin' implies a non-atomic operation, where, e.g. a new file could be
> > written to /bin after the xattr tagging started.
> 
> An inheritance issue, similar to ACLs or SELinux attributes.  Newly
> created files could inherit the audit attribute of the directory in
> which they were created by default.

Let's say you have a policy which says that you had to audit anything
which happens to the file /foo/bar.txt , but the policy does not require
anything else under /foo to be audited.

The administrator deletes /foo/bar.txt.  This is audited, as it was
labeled during installation.

The administrator creates /foo/bar.txt.  This is not audited, as the file 
does not inherit a security.audit flag from /foo.  Further changes to the 
file are not audited.

In practice, the system could be implemented to avoid this issue, but it
is a potential pitfall.

> > I think it's better to have a centralized policy which can be updated
> > atomically and applied within the kernel, rather than being distributed
> > with each object to be audited.
> 
> Sounds like you are arguing against using attributes for SELinux too ;)

Well, not exactly, but it means that the audit subsystem would need to be
designed to address similar problems, e.g. take into account the
difference between labeling inheritance rules and the full labeling
specification, restoring the correct labels on files after shutdown etc.

Another potential issue is that file auditing would then be limited to
filesystems which support extended attributes and a security namespace
handler.  I don't know if this would be a problem for certification.


- James
-- 
James Morris
<jmorris at redhat.com>