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 -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-selinux-list
