Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

["Serge E. Hallyn" <serue@us.ibm.com>]

Quoting Arjan van de Ven (arjan@infradead.org):
> On Tue, 2006-04-18 at 12:31 -0700, Crispin Cowan wrote:
> > Karl MacMillan wrote:
> > > Which is one reason why SELinux has types (equivalence classes) - it
> > > makes it possible to group large numbers of applications or resources
> > > into the same security category. The targeted policy that ships with
> > > RHEL / Fedora shows how this works in practice.
> > >   
> > AppArmor (then called "SubDomain") showed how this worked in practice
> > years before the Targeted Policy came along. The Targeted Policy
> > implements an approximation to the AppArmor security model, but does it
> > with domains and types instead of path names, imposing a substantial
> > cost in ease-of-use on the user.
> 
> I would suspect that the "filename" thing will be the biggest achilles
> heel...
> after all what does filename mean in a linux world with
> * hardlinks
> * chroot
> * namespaces
> * bind mounts
> * unlink of open files
> * fd passing over unix sockets
> * relative pathnames
> * multiple threads (where one can unlink+replace file while the other is
> in the validation code)

My old dte module addressed all of these by keeping an in-kernel map
of vfsmounts.  Ok, all the interesting ones - three of them are
solved just by appropriately using file->f_security.

Hardlinks are a pain, but you just have to make up your mind how to
solve them.  In selinux (i believe) the solution is "the first name to
match a rule wins" during labeling, and of course at run-time the labels
are taken from xattrs, and newly created files are based on parent dir
and creating process.  It may be solved in selinux, but since at some
point all initial files must be labeled based on pathname, it still is
an issue to be addressed.

I am curious to see how subdomain will solve these.  And LIDS.  Have
they switched to a install-time xattr labeling + file transition rules
scheme like selinux?  We'll see, it could be interesting.  (Or, it could
be uninteresting and completely wrong...)

-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/