[RFC] Testcase Scenarios for Auditfs Code

[Serge Hallyn]

On Mon, 2005-05-02 at 14:15 -0400, Stephen Smalley wrote:

> 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

Now this is disconcerting - the last time I tried this, not too long
ago, I was not able to bind mount files, only directories.

Of course if we were going to worry about this, then we should also
worry about the simpler 'mount --bind /tmp/evil_etc /etc' or even
simpler mounts.  Since we don't worry about those, adding extra hooks to
deal with the mount bind file case would be unwarrented.  (right?)

Still the problem is interesting  :)  And easier to solve than bind
mount directory.  It should be solvable by hooking security_sb_check_sb,
right?

What does the fs tree look like at that point?  Is shadow simultaneously
a vfsmount and a dentry?

> 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.  How bad would it be to have the kernel create a inode-based
audit rule when the new /etc/shadow (or any name-watched file) is
created?

If we stick with the idea of keeping name- and inode-based watches
separate, then the semantics that name-based watches create an inode-
based watch whenever a new `name` is created, I think that would be
pretty intuitive.

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

How would it be done with selinux?  For shadow, I can see a clear
solution - it only creates files of type shadow_t under /etc, so a
simple type_transition rule with no rewriting of passwd can give you a
label to audit on.  But for the general case, I would expect you'd need
to rewrite application_foo to create the files to be audited with a
particular type echo'd into /proc/self/attr/fscreate.  Or is there
another way selinux could be used?

thanks,
-serge

-- 
Serge Hallyn <serue at us.ibm.com>