Hi,

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 [1]

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?

Cheers,
Edwin
[1]http://www.uwsg.iu.edu/hypermail/linux/kernel/0604.0/0133.html