[RFC] Testcase Scenarios for Auditfs Code

[Stephen Smalley]

On Fri, 2005-04-29 at 14:57 -0500, Klaus Weidner wrote:
> didn't we have this discussion already a couple of months ago? :-(

I don't think it has been clearly articulated in the past, at least not
on this list, so I appreciate you taking the time to do so.

> When the integrity is important, you want access to a hard link audited
> as long as the link is pointing to the same file. When the link is broken
> (i.e. due to the original name being removed), you don't care anymore
> about access to the link. You do want audit to start for a new file being
> created at the old location.

But until the link is broken, you want the auditing preserved, right?
And this is currently violated both under memory pressure and upon
reboot (unless an inode-based filter is _also_ applied in addition to
the watch on the original link or unless you add a watch on the new hard
link), right?

With regard to creation in a watched location, do you also want to audit
the effects of 'mount --bind myshadow /etc/shadow'?  I know that you are
assuming a non-malicious admin, but given that you do want to audit re-
creation of /etc/shadow even though /etc/shadow can only be modified by
privileged processes, shouldn't you also want to audit bind mounting
over the file? 

> Rebooting is not a problem, you would configure the audit system to
> add both an inode based audit rule and a watch list for /etc/shadow since
> it needs audit for both confidentiality and integrity. That way access to
> the link would still be audited after the reboot.

Ok, for /etc/shadow.  But for files where you are only concerned about
integrity, it seems like a weakness in the watch mechanism.

> No, that's not the desired behavior, and I had expected that the audit
> information would be locked in memory to prevent this. It could be worked
> around by creating both inode based rules and watch lists for trusted
> databases.

It seems like it would be better to make the watch mechanism consistent
in how it handles hard links, either _not_ preserving auditability at
all (in the absence of a separate watch on the new hard link) or
guaranteeing preservation of auditability until the original link is
removed.  Just some stable semantics that will make sense to users.

> Serge has suggested some more abstract user-space tool to make this less
> confusing, something like:
> 
> 	auditfs add secrecy /etc/shadow (watch the inode)
> 	auditfs add integrity /etc/shadow (watch the pathname)
> 
> and the combination of both would also preserve the secrecy of newly
> created, renamed, or linked /etc/shadow files.

Yes, this would help.  Writing inode-based filters presently is rather
painful compared to writing watches, and I'm not clear that you can
easily specify things like "Show me all opens with write access
to /etc/shadow" using the syscall filter specifications.  

> If someone has a different way to solve the integrity/pathname-based
> audit problem (preferably without needing invasive changes to userspace
> tools), please share that information.

In SELinux, we'd tend to approach the problem a bit differently, but I
understand you are trying to achieve CAPP without any dependency on
SELinux.

-- 
Stephen Smalley <sds at tycho.nsa.gov>
National Security Agency