Limiting IPC with SELinux?

[Steve Brueckner]

Stephen Smalley wrote:
> On Thu, 2005-04-14 at 16:33 -0400, Steve Brueckner wrote:
>> I need to lock down the local interprocess communications (sockets,
>> pipes, shared memory...) for a few untrusted applications under the
>> targeted policy.  For example, I want to write policies for Mozilla
>> and Eclipse such that Eclipse may connect to Mozilla's tcp socket 80
>> via loopback, but Eclipse may not connect to any other process's tcp
>> socket 80 via loopback. Same thing goes for other methods of IPC.
> 
> You mean apache rather than mozilla, right?

I actually do mean Mozilla, but I guess I don't mean port 80 (it's some
other high port number).  Eclipse's help system launches Mozilla to access
the help docs on the local hard drive, and they communicate via loopback.
The problem for me is how to allow this, but not allow Eclipse to
communicate with any other local processes via loopback.  The hard part is
that I can't make this decision based on port number; it has to be based on
the actual processes involved.

>> I suspect this means I have to figure out how to label sockets and
>> the like with special contexts as they are created.  Am I on the
>> right track here? If so, how would I adjust my policies to label
>> these IPC resources on a per-process basis?  Or is this not do-able
>> with SELinux? 
> 
> You can control network communication (loopback or otherwise) via the
> permission checks between the sending socket security context and the
> security contexts of the network interface, the destination host, and
> the destination port.  These are the netif and node tcp_send
> permissions and the tcp_socket send_msg permission.  Sockets are
> labeled in accordance with the creating process, so you just need to
> define a domain for eclipse.      

Since I can't statically define security contexts for specific port numbers
in my policy, I may have a problem.  I think my first example above
illustrates this: either Mozilla or a hostile process could be listening on
the port, so Eclipse needs to know which process is listening on that port.
For my application, I can't deny any process the right to bind to whatever
port it wants.  Keep in mind that this is all happening on the local
machine, so I also can't use network interface or destination host to
differentiate, either.
 
>> What I'm proposing here is a little more involved than most of the
>> SELinux documentation I've found online, so any good resources would
>> be appreciated. Of course, the more that is spelled out for me in a
>> direct reply the bigger my head start will be.  At this point I don't
>> even know where to begin.
> 
> Possible resources:
> (...lots of good links listed here...)

Thanks for the links.  I reviewed most of them a while back, but I just
refreshed myself on the networking portions.

> And going back to your original question, for INET communication, you
> can't truly do process-to-process permission checks (or even
> socket-to- peersocket permission checks) because we don't presently
> have labeled networking support (i.e. labeled network buffers and
> packets).  There was experimental support for such labeled networking
> in the older SELinux (courtesy of James Morris), but the necessary
> hooks and security fields to support it were not accepted into Linux
> 2.6.  Trent Jaeger of IBM has more recently implemented implicit
> packet labeling via IPSEC security associations for SELinux, but I
> don't think you need that for what you describe; the existing
> permission checks based on network interface, host, and port should
> be sufficient.           

Ah, so maybe I can't do exactly what I want to do using SELinux.  My network
interface and host will always be the same, so no help there.  And I can't a
priori decide which ports to allow or disallow.  I think what I need is the
ability to say "eclipse_t may connect only to a socket belonging to
mozilla_t," where the socket gets labeled as belonging to mozilla_t when
Mozilla first calls socket() or bind().

Also, this is not just about networking.  I need to make the same
process-to-process decision for other types of IPC, such as shared memory.
However, this may be possible:  I assume that unlike a socket, a shared
memory segment gets labeled with the context of the domain that created it?
So I could write a rule such as "allow eclipse_t mozilla_t:shm {read write}"
to allow Eclipse and Mozilla to share memory with each other but nobody
else?  (of course now I'm just using Eclipse and Mozilla as examples; these
could be any programs).

So, based on my clarifications above, what are my chances of pulling this
off?  I'm afraid that unless my understanding is fundamentally flawed, I may
be goind beyond what SELinux can currently support.  A shame about the
labeled networking support being shot down by the kernel folks.

Thanks,

 - Steve Brueckner, ATC-NY