<snip> > Subject: Re: Exposing secid to secctx mapping to user-space > > On 12/13/2015 2:06 PM, Paul Moore wrote: > > On Friday, December 11, 2015 05:14:38 PM Stephen Smalley wrote: > >> Perhaps we could provide a new fixed-size tokenized version of the > >> security context string for export to userspace that could be > >> embedded in the binder transaction structure? This could avoid both > >> the limitations of the current secid (e.g. limited to 32 bits, no > >> stackability) and the overhead of copying context strings on every IPC. > > On Friday, December 11, 2015 04:24:48 PM Casey Schaufler wrote: > >> How about this: Provide an alias mechanism for secctx. There would > >> then be a secid (32bits) a secctx (arbitrary text string) and a > >> secalias which could be a limited string of some length. You could > >> use the alias in place of the secctx anywhere you liked. > > My initial reaction to the secalias idea isn't overly positive. It > > seems like a kludge with a lot of duplication, both in terms of code > > and concept, and a lot of risk for confusion both by users and policy > > writers. I think if we really wanted to limit the security label > > string format to a small size we should have done that from the start, it's too > late now. > > The alias would be a user space controlled mapping. The kernel code would only > be involved at the border. I would never expect policy to be written using aliases. > As for being a kludge, yeah, there's some of that, but I think that's true with the > secid, too. > > > Assuming we see some binder performance numbers, and the numbers are > > bad, I'm a little more open to doing something with the secid token. > > Up to this point we haven't made any guarantees about the token and we > > haven't exported it outside the kernel so there is some ability to change it to fit > our needs. > > Granted, this isn't perfect solution either, and perhaps ultimately we > > would need something else, but I think it is worth looking into this > > first before we introduce another string label. > > I agree with getting numbers before someone dashes off to make a premature > optimization that exposes secids. If the numbers are bad I would hope that the > developers would look at fixing binder rather than exposing (and forever > requiring) secids. > If I understand correctly, the goal here is to avoid the lookup from pid to context. If we somehow Had the context or a token to a context during the ipc transaction to userspace, we could just use that In computing the access decision. If that is correct, then since we have PID, why not just extend the SE Linux compute av decision interface to support passing of PID and then it can do the lookup in the Kernel? _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
