Re: [RFC][PATCH 0/7] fireflier LSM for labeling sockets based on its creator (owner)

[Chris Wright]

* Török Edwin (edwin@xxxxxxxxx) wrote:
> 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]

There is so much SELinux code in here, it's really not making sense to
do this as separate work.

> 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

That sounds like a problem.  Ptrace can undermine that really easily.
Also bind mounts will give you a different sid for same exectuable, with
a possible way to get into interesting 'group' situation.
 
> - 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"

How do you keep from joining the group?

> 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?)

what do you do about ptrace, /proc/[pid]/mem, fd passing, bind mounts, /proc/self/mem, etc.

> - how do I generate an SELinux policy, that does what this LSM module does?

Sounds like the best solution.

thanks,
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/