On 12/14/2015 04:29 PM, Roberts, William C wrote:
<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?
That's no less racy than getpidcon().
_______________________________________________
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.
