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

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

Quoting T?r?k Edwin (edwin@gurde.com):
> On Tuesday 18 April 2006 22:50, Arjan van de Ven wrote:
> >
> > 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)
> 
> FYI fireflier v1.1.x created rules based on filenames.
> In the current version we intended to use mountpoint+inode to identify 
> programs. This reduces the potential problems from your list to: fd passing.
> 
> Can't AppArmor use inodes in addition to filenames to implement its rules? 
> The user could still make its choice based on a "filename" (in an interactive 

Doesn't help with, for instance, /etc/shadow.  Run passwd once and the
inode number is obsolete.

So either you find a way to decisively use the pathname to identify it,
or you make sure that anyone who can replace it, labels it.

> - use extended attributes to label files, using selinux's setfiles. Most 
> secure option IMHO

Again, xattrs alone may be insufficient if the file can be replaced.

> - store rules based on mountpoint+inode+program hash/checksum, and then get 
> selinux to label files according to this. Not sure how to do this, and if it 
> is worth at all

Again, you're only addressing initial labeling.  But I guess you're
labeling executables so that should be fine.

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