Messages in this thread | | | Date | Tue, 18 Apr 2006 15:42:27 -0500 | From | "Serge E. Hallyn" <> | Subject | Re: [Fireflier-devel] Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks |
| |
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/
| |