On Sun, Dec 13, 2015 at 5:06 PM, Paul Moore <paul@xxxxxxxxxxxxxx> 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. > > 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. Agreed here. I can definitely see a use for security identifier tokens in SE Postgres as well. Ideally these tokens would be 32 bit uints as opposed to shorter string aliases. --Mike > > -- > paul moore > www.paul-moore.com > > _______________________________________________ > 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. _______________________________________________ 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.
