[RFC] Testcase Scenarios for Auditfs Code

[Klaus Weidner]

On Mon, May 02, 2005 at 02:15:32PM -0400, Stephen Smalley wrote:
> On Fri, 2005-04-29 at 14:57 -0500, Klaus Weidner wrote:
> > 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?

The memory pressure issue does need to be solved, it's not acceptable
that file audit gets disabled when memory is running low.

For reboots, the normal way to use the watch list would be to load a set
of watches as part of the boot process. Adding a watch to a path adds
audit information to the inode corresponding to that path, so as long as
the hard link is unbroken, access via the hard link is automatically also
audited. In this case you're not losing any information across a reboot
and don't need a separate inode based filter.

> 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? 

The important difference is that /etc/shadow is recreated whenever an
unprivileged user runs the SUID "passwd" program; that's a part of
regular system operation and we need to be able to deal with that. But
the "passwd" program won't create any bind mounts, and it's a reasonable
restriction to tell admins not to do that.

> > 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.

My example was misleading, the current watch list approach does handle
this appropriately even without an extra inode based rule. Here's an
example:

	add watch for /etc/hosts
	create hard link: ln /etc/hosts /tmp/hack

	reboot
	[ as part of reboot, add watch for /etc/hosts again ]
	write to /tmp/hack

The access to the hard link will generate an audit record, the audit
information is associated with the inode when adding the watch list
entry. There's no need to add an explicit watch for /tmp/hack to get that
audited.

> > 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.

I agree that the semantics should be stable, and the preferable solution
would be guaranteed audit of access to the inode via hard links as long
as any one of the hard links is covered by a watch list entry. That is
how the current code works except for the memory pressure issue, and
that's on the list of things to fix, right?

-Klaus