Auditing - Snare, LAuS, SELinux

[Stephen Smalley]

On Wed, 2004-09-08 at 11:11, James Morris wrote:
> If someone manages to modify/remove the xattr, then further auditing would
> not work for that file.  How do you stop this from happening in a DAC
> system?  With a centralized audit policy, you only need to protect the 
> path through which the policy is loaded.

The default inode_setxattr and inode_removexattr hook functions require
CAP_SYS_ADMIN to set or remove an attribute in the security namespace. 
So security.audit would be protected against non-superuser tampering
even without SELinux.

> How do you manage global audit policy?  e.g. the question 'which files
> will be audited?' requires a non-atomic scan of the entire filesystem.

You would still likely have a centralized config for initializing the
audit tags, similar to the file_contexts configuration for initializing
the SELinux security labels, but you need those tags to be bound to the
real objects for runtime operation.  Given that the audit tags can only
be changed by approved processes, one can always ensure that the
userspace component for updating the audit tags also updates that
centralized config for reference.

> 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.  Of course, this doesn't address all
issues of preserving such attributes, but programs are already being
modified to preserve attributes to support SELinux and ACLs, so this is
not a new requirement.

> 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 ;)
But the point is that pathnames do not identify objects, and we
ultimately need to audit (and control) access to the actual objects if
we are going to track (and control) real information flow in the system.

-- 
Stephen Smalley <sds at epoch.ncsc.mil>
National Security Agency