On Thu, May 14, 2020 at 10:57 AM Paul Tagliamonte <paultag@xxxxxxxxxx> wrote: > > > Was computing the MLS label the only part you needed? With respect to > > having the daemon run in the same label as the peer (or the label > > derived from the intersection of the peer and the daemon), you may > > wish to have a look at mod_selinux for Apache and/or the old xinetd > > LABELED option, although neither of those would have included the new > > glblub support so you'll have to integrate that yourself. > > Ah, really helpful pointers, thank you very much! > > > Or your daemon can just use setcon(3) directly if allowed by policy. > > My assumption was that I can use the greatest lower bound, and then > preform a `setexeccon` and `exec` to transition to the new security > context provided I can pass the open fd according to policy (for > now -- at least until I can find a better way to restrict a thread -- I'll > do some reading in mod_selinux / xinetd). Is this the case, or am > I going to wind up in a world of hurt? setcon(3) would avoid the need for a separate exec but requires more trust in the caller. Up to you as to which model works for your use case. Originally SELinux only supported setexeccon(3) but setcon(3) was added particularly for MLS users and has since been leveraged elsewhere. mod_selinux uses setcon(3). xinetd LABELED uses setexeccon(3) since it was already exec'ing a separate child daemon. > The use-case here is to allow an RPC server to listen to network > traffic, and when properly authenticated, raise the sensitivity level > and category as required, both so the RPC server can logically > handle access controls (not shocked the crunchy folks hit this first) > as well as a system level protection in case there's a slip up and > the server attempts to read a secure file (less urgent but still > very nice to have!). > > I'm very much still learning the MLS ropes here, so if someone > sees me hurtling to the edge of a cliff, do let me know!
