Messages in this thread | | | From | Török Edwin <> | Subject | Re: [Fireflier-devel] Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks | Date | Tue, 18 Apr 2006 23:13:05 +0300 |
| |
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 userspace program), but by storing additional info along with the filename in the rules it would at least uniquely identify the program. (P.S.: I don't know how apparmor works, so what i said might not be directly applicable).
Note, that since fireflier is going to use SELinux (as soon as I get the policy done) program identification isn't shouldn't be a problem for fireflier, but we still have two alternatives:
- use extended attributes to label files, using selinux's setfiles. Most secure option IMHO (BTW can SELinux be told to use another xattr instead of security.selinux? Purpose: having multiple policies, and switching between them without the need to relabel, i.e. switching between a distro-provided policy/ a custom policy/ a fireflier generated policy)
- 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
Cheers, Edwin - 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/
| |