Re: Auditing - Snare, LAuS, SELinux
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(a)redhat.com>