Re: [RFC] Testcase Scenarios for Auditfs Code
On Mon, 2005-05-02 at 14:59 -0500, Klaus Weidner wrote:
The memory pressure issue does need to be solved, it's not
acceptable
that file audit gets disabled when memory is running low.
Right, so auditfs needs to hold a reference to the dentry from the time
the watch is inserted, right? Thereby pinning it and the associated
inode in memory?
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.
Ah, I missed that point - thanks for clarifying.
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.
Ok, fair enough. Although it might still be useful for all mount
operations to be audited for use in later analysis of the audit logs,
whether such auditing is done in userspace by the mount program or by
the kernel, depending on your threat model.
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.
Ok, good.
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?
I believe so.
--
Stephen Smalley <sds(a)tycho.nsa.gov>
National Security Agency