Re: [RFC] Testcase Scenarios for Auditfs Code
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(a)us.ibm.com>