On Fri, 2005-04-15 at 13:47 -0400, Steve Brueckner wrote:
> 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.
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.
Note btw that the targeted policy doesn't presently define domains for
user applications like mozilla or eclipse; it is focused on a subset of
the daemon domains and leaves users and user applications running
unconfined. strict policy includes domains for users and their
applications, although most user applications still run in the base user
domain (mozilla is an exception).
> 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?
> 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().
The sockets are labeled (with the same label as the creating process).
The problem is conveying that label on an INET communication so that the
receiver can perform a socket-to-peersocket check, which is presently
lacking due to the lack of labeled networking. But it can be done for
PF_UNIX/LOCAL communication and for other forms of local IPC.
> 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).
Yes. Look for example at policy/macros/program/x_client_macros.te,
where the X client is allowed to communicate with the X server via
shared memory. Note that this involves both rules on the "shm" object
class and permissions on "tmpfs" files, because the kernel maintains an
internal tmpfs mount representing shm objects.
> 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.
Only for local communications (PF_UNIX/LOCAL, System V IPC, etc). For
INET communications, you are limited to port-based controls, so you need
to be able to establish control over the process-to-port bindings if you
want to achieve process-to-process control.
--
Stephen Smalley <sds@xxxxxxxxxxxxx>
National Security Agency
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-selinux-list
