On Fri, 2007-11-09 at 14:51 -0500, Stephen Smalley wrote: > On Fri, 2007-11-09 at 19:48 +0000, David Howells wrote: > > Okay, it looks like it's probably the problem I'm thinking of. If it is, I > > need to think carefully about how to deal with it. > > > > Stephen: Would it be possible for me to create the per-UID keyring without > > reference to the security label of the current process? > > > > The other alternative is to accept that if the label can't be linked because > > of a security label disagreement than that's that, and we don't give an error. > > > > I don't like that second option, though, because that can seriously limit the > > utility of the per-UID keyring by it being a lottery as to what label it gets > > created with - basically who gets to try creating it first. > > > > Any suggestions? > > (taking discussion back on list) > > We already provide a way to create a key with a specified label other > than the current process, via setkeycreatecon(3) aka writing the label > to /proc/self/attr/keycreate before allocating the key. > > So why can't the userland code that is allocating these per-uid keyrings > use that interface to set the context appropriately for the actual user > rather than defaulting to its own context? Ah, wait - this is an automatic allocation of a per-uid keyring upon a setuid() call, right? So here we have a kernel-internal allocation of the keyring (so userland doesn't know it needs to setkeycreatecon, and requiring it to do so seems a bit clunky), yet on the other hand, we don't presently have a way to map a Linux uid automatically to a SELinux security context in the kernel - that's managed in userspace, and a single Linux uid might ultimately have a number of SELinux security contexts running on its behalf. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
