[RFC] Testcase Scenarios for Auditfs Code

[Stephen Smalley]

On Mon, 2005-05-02 at 14:09 -0500, Serge Hallyn wrote:
> Now this is disconcerting - the last time I tried this, not too long
> ago, I was not able to bind mount files, only directories.

Only restriction I see is that the source and target have to be
consistent, i.e. either both are non-directories or both are
directories, so you can mount a file on a file.  That's why SELinux puts
'mounton' permission in the common file definitions inherited by both
file and dir.

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

True, and based on Klaus' comments, it doesn't need to be addressed.  

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

With SELinux, we can ensure that such files are only modified by
approved programs, and that trusted programs cannot take as input files
that can be modified by untrustworthy programs, so even if a malicious
process creates a "bad" /etc/shadow, we can ensure that the data in
that /etc/shadow is never used by a privileged process.  It does require
program modifications to preserve attributes when a single program re-
creates multiple files in the same parent directory and those files need
different attributes (as has already been done for a variety of programs
in Fedora, including not only shadow utilities but even programs like
vi), but such modifications are ultimately necessary for preservation of
any kind of fine-grained protection, whether via SELinux or POSIX ACLs.

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