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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
