RE: Limiting IPC with SELinux?

[Steve Brueckner]

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

Limiting IPC with SELinux?

[Thomas Bleher]

* Steve Brueckner <steve(a)atc-nycorp.com&gt; [2005-04-22 19:01]:
>  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. 
[ lots of good observations snipped ]

I had an idea a while ago which may help you. I wanted to implement it
myself but don't have time to do any kernel-hacking currently, so if you
want to try it, feel free.
My idea was to build an iptables modules similar to the "Owner match"
module which matches locally generated packets against a specific domain.
That way you could probably achieve most of what you want.
One problem here is: how do we cleanly match on security context? All 
the logic should be in the security server and controllable by policy.
The most sane way I came up with is this:
Declare a new class "iptables" (or "netfilter") with one permission
"match". Then put this into policy:
	allow domain self:iptables match;
The usermode iptables code passes a complete security context into the
kernel which is converted into a sid internally. Now everytime the
iptables module is called on a packet it asks the avc if <sid of sending
packet>:<sid passed into kernel>:IPTABLES__MATCH is allowed in the
policy.
I do not know if this is the best approach but it does allow matching on
specific domains, on specific contexts (if the constraints are adjusted)
or on a group of domains (you could add a dummy type all_userdomains_t
and add "allow userdomain all_userdomains_t:iptables match;" or
something like that and then match on all_userdomains_t in the iptables
rule)

I think such a module would be very useful. For example, the admin may
want to specify that mozilla may only talk to the internal proxy server.

Of course, this depends on the fact that such a module is actually
doable and sane. I looked at the code but I am no kernel hacker so I
would appreciate any insight/ideas.

Thomas

-- 
http://www.cip.ifi.lmu.de/~bleher/selinux/ - my SELinux pages
GPG-Fingerprint: BC4F BB16 30D6 F253 E3EA  D09E C562 2BAE B2F4 ABE7

Limiting IPC with SELinux?

[Stephen Smalley]

On Fri, 2005-04-22 at 20:46 +0200, Thomas Bleher wrote:
>  I had an idea a while ago which may help you. I wanted to implement
> it
>  myself but don't have time to do any kernel-hacking currently, so if you
>  want to try it, feel free.
>  My idea was to build an iptables modules similar to the "Owner match"
>  module which matches locally generated packets against a specific domain.
>  That way you could probably achieve most of what you want.
>  One problem here is: how do we cleanly match on security context? All 
>  the logic should be in the security server and controllable by policy.
>  The most sane way I came up with is this:
>  Declare a new class "iptables" (or "netfilter") with one permission
>  "match". Then put this into policy:
>  	allow domain self:iptables match;
>  The usermode iptables code passes a complete security context into the
>  kernel which is converted into a sid internally. Now everytime the
>  iptables module is called on a packet it asks the avc if <sid of sending
>  packet>:<sid passed into kernel>:IPTABLES__MATCH is allowed in the
>  policy.
>  I do not know if this is the best approach but it does allow matching on
>  specific domains, on specific contexts (if the constraints are adjusted)
>  or on a group of domains (you could add a dummy type all_userdomains_t
>  and add "allow userdomain all_userdomains_t:iptables match;" or
>  something like that and then match on all_userdomains_t in the iptables
>  rule)
>  
>  I think such a module would be very useful. For example, the admin may
>  want to specify that mozilla may only talk to the internal proxy server.
>  
>  Of course, this depends on the fact that such a module is actually
>  doable and sane. I looked at the code but I am no kernel hacker so I
>  would appreciate any insight/ideas. 
LIDS seems to have supported something similar at one time using the
iptables MARK module:
http://www.lids.org/document/lids_worm.html

-- 
Stephen Smalley <sds(a)tycho.nsa.gov&gt;
National Security Agency

Limiting IPC with SELinux?

[James Morris]

On Fri, 22 Apr 2005, Steve Brueckner wrote:

>  return ephemeral ports.  Or is there a chance of re-visiting the idea
> of
>  getting labeled networking into the kernel? 
Work is being done on labeled networking via IPsec, see Trent Jaeger's 
paper at http://www.selinux-symposium.org/2005/agenda.php



- James
-- 
James Morris
<jmorris(a)redhat.com&gt;

Limiting IPC with SELinux?

[Stephen Smalley]

On Fri, 2005-04-22 at 14:58 -0400, James Morris wrote:
>  On Fri, 22 Apr 2005, Steve Brueckner wrote:
>  
>  > return ephemeral ports.  Or is there a chance of re-visiting the idea of
>  > getting labeled networking into the kernel?
>  
>  Work is being done on labeled networking via IPsec, see Trent Jaeger's 
>  paper at http://www.selinux-symposium.org/2005/agenda.php 
True, but I don't think this will help much in this particular case, as
the original poster wants to control information flow via loopback and
you aren't likely to be using IPSEC on such traffic.  In the absence of
a sk_buff security field and associated hooks for lifecycle management,
I think that we'd have to go with something like the iptables MARK
module, ala LIDS.
 
-- 
Stephen Smalley <sds(a)tycho.nsa.gov&gt;
National Security Agency

Limiting IPC with SELinux?

[Stephen Smalley]

On Mon, 2005-04-25 at 08:38 -0400, Stephen Smalley wrote:
>  On Fri, 2005-04-22 at 14:58 -0400, James Morris wrote:
>  > On Fri, 22 Apr 2005, Steve Brueckner wrote:
>  > 
>  > > return ephemeral ports.  Or is there a chance of re-visiting the idea of
>  > > getting labeled networking into the kernel?
>  > 
>  > Work is being done on labeled networking via IPsec, see Trent Jaeger's 
>  > paper at http://www.selinux-symposium.org/2005/agenda.php
>  
>  True, but I don't think this will help much in this particular case, as
>  the original poster wants to control information flow via loopback and
>  you aren't likely to be using IPSEC on such traffic.  In the absence of
>  a sk_buff security field and associated hooks for lifecycle management,
>  I think that we'd have to go with something like the iptables MARK
>  module, ala LIDS. 
Actually, Thomas Bleher's suggestion of extending the ipt owner module
might be better.

-- 
Stephen Smalley <sds(a)tycho.nsa.gov&gt;
National Security Agency

Limiting IPC with SELinux?

[James Morris]

On Mon, 25 Apr 2005, Stephen Smalley wrote:

>  Actually, Thomas Bleher's suggestion of extending the ipt owner
> module
>  might be better. 
The upstream module only works for outgoing packets, and also imposes some 
heavy locking.

For outgoing packets we already have the security context via the owning 
socket, and for incoming packets we probably need to hook sock_rcv_skb.

In any case, I didn't understand the idea of adding a permission for all 
matches, when the SELinux code doesn't understand why the packet was being 
matched or what is supposed to happen to it.


- James
-- 
James Morris
<jmorris(a)redhat.com&gt;

Limiting IPC with SELinux?

[James Morris]

On Mon, 25 Apr 2005, Stephen Smalley wrote:

>  True, but I don't think this will help much in this particular
> case, as
>  the original poster wants to control information flow via loopback and
>  you aren't likely to be using IPSEC on such traffic. 
You could use null encryption and null authentication.

Another possibility is to implement SO_PEERSEC for loopback TCP, although 
I think it requires more LSM hooks.

>  In the absence of a sk_buff security field and associated hooks for
>  lifecycle management, I think that we'd have to go with something like
>  the iptables MARK module, ala LIDS. 
I think this is at the wrong layer; how would you query the socket for 
peer security information?


- James
-- 
James Morris
<jmorris(a)redhat.com&gt;