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. -- paul moore www.paul-moore.com -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
