On Thu, May 14, 2020 at 11:30 AM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > 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 ... One also has to be careful when using setcon() as it only affects the domain of the running task and not any transient objects that may have been created and which the task might expect to be able to access (which of course is the right thing to do). If it fits within your model, setexecon()/exec() is easier, safer, etc. -- paul moore www.paul-moore.com
