[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: Limiting IPC with SELinux?



I've been experimenting with the SELinux networking permissions, based on
last week's emails on this topic.  I've run into a problem:

Stephen Smalley wrote:
> Well, SELinux does allow you to limit what processes can bind to what
> ports, so if the port falls within a well-defined range and you can
> exclude others from that port range without breaking functionality,
> you can indirectly achieve the process-to-process relationship in
> that manner.  If not, then I guess you need labeled networking.    
>
>> On Fri, 2005-04-15 at 13:47 -0400, Steve Brueckner wrote:
>> For my application, I can't deny any process the right to bind to
>> whatever port it wants.
> 
> This seems to be the key limitation.  The question is why?

My application is trying to segregate the machine into two protection
domains, and I don't have control over the programs that may run in either
domain.  I need to allow processes to communicate via loopback networking
intra-domain but not inter-domain.  Let's look at the cases of (1) tcp and
(2) udp:

(1) For tcp, this domain segregation would seem to be possible using the
name_bind and (forthcoming with 2.6.12) name_connect permissions.  I could
allow processes in each domain to bind and connect only to ports defined as
belonging to that domain.  The ports from which connections originate will
likely be ephemeral ports issued by the kernel, but that's OK: I can allow
send to and recv from all ports as long as the name_bind and name_connect
are enforced.

By loosening the requirements of my application, I can indeed set aside port
ranges for each domain.  However, I still don't have control over
applications' internals.  And some applications are troublemakers in that
they bind not to a port specified in their configuration, but to an
ephemeral port handed to them by the kernel.  Such applications (e.g.
passive FTP) will simply break when the kernel hands them a port that is not
within their domain, and cannot easily be fixed.

(2) For udp, things break even more easily.  I could allow processes in each
domain to bind only to ports belonging to their domain.  But since udp
doesn't connect, I'd have to limit the send and recv ports.  Limiting send
and recv to ports belonging to a domain works for clients trying to talk to
a bound server, but not for the bound server itself.  Bound servers would
break since they would be trying to send to and receive from clients using
ephemeral ports that may be outside their domain.

It seems to me that this is a problem for anyone wanting to use SELinux or
SELinux with MLS in such a way.  I don't think it's a stretch to imagine
that some folks will desire the ability to enforce domain separation without
shutting down loopback networking.  If this can't be done now, is there a
chance it will be addressed in the future?  What appears to be needed is
some way to make the kernel security context-aware when assigning ephemeral
ports.  My temporary solution may be to wrap or hack the kernel calls that
return ephemeral ports.  Or is there a chance of re-visiting the idea of
getting labeled networking into the kernel?

Stephen Brueckner, ATC-NY


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]