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

Serge E. Hallyn
2006-04-18T20:42:38Z

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