|| ||=?utf-8?q?T=C3=B6r=C3=B6k_Edwin?= <firstname.lastname@example.org>|
|| ||[RFC][PATCH 0/7] fireflier LSM for labeling sockets based on its creator (owner)|
|| ||Fri, 7 Apr 2006 21:24:23 +0300|
|| ||James Morris <email@example.com>, firstname.lastname@example.org,
The purpose of the fireflier LSM is to "label" each socket with a context,
where the context is a (list of) the program(s) that has/have access to it.
I've written fireflier LSM to allow filtering packets "per application". It is
meant to be used only when SELinux is not available (not available/disabled
at boot). For more details, see the initial discussion 
Summary of how fireflier LSM works:
- each program is associated a sid, depending on its mountpoint+inode, i.e. 2
processes launched from the same program have the same sid
- each socket created by a processis labeled with the process's sid
- if 2 or more programs have access to the socket, it is labeled with a "group
sid". A group sid contains a list of the sids of programs having access
- userspace, or iptables module can match packets on this "fireflier context"
As I stated in my previous mail, I intend to write a userspace policy module
generator, that is to be used when selinux is enabled.
When it is disabled, then only would the fireflier lsm be used.
I am asking for your comments/suggestions on the following issues:
- security/correctness of the LSM (is there a way for a program to have access
to a socket, and escaping the labeling?)
- how do I generate an SELinux policy, that does what this LSM module does?
If (and when) I succeed in writing this userspace policy generator, the
fireflier lsm might be dropped, and replaced with the policy generator:
even if the user has no selinux policy & tools, he can use fireflier policy
generator for labeling only, all he has to do, is boot with selinux=1.
However on many distributions in that case a default policy is loaded, so we
would have to deactivate that (we can't _require_ the user to actually have
selinux set up). Not really a nice solution.
However dropping the lsm module can be done only in the fireflier 2.1, or 2.2
it will most probably be included in fireflier 2.0 (currently in beta).
@Martin Maurer: what is your opinion on this?