On 12/11/2015 02:55 PM, Paul Moore wrote:
On Fri, Dec 11, 2015 at 1:37 PM, Daniel Cashman <dcash...@android.com> wrote:
Hello,
I would like to write a patch that would expose, via selinuxfs, the
mapping between secids in the kernel and security contexts to
user-space, but before doing so wanted to get some feedback as to
whether or not such an endeavor could have any support upstream. The
direct motivation for this is the desire to communicate calling security
ids/contexts over binder IPC on android for use in a user-space object
manager. Passing the security ids themselves would be simpler and more
efficient in the critical kernel path, but they currently have no
user-space meaning.
In general we try to avoid exposing the secid tokens outside the
kernel, I view them as an implementation hack designed to make it
easier to manage and operate on the security labels in the kernel. I
suspect you will hear something very similar from Casey and the other
Smack developers. Another consideration is the long standing LSM
stacking effort, they have several good reasons for wanting to abolish
the secid token, propagating it to userspace would make that all but
impossible.
While I'm sympathetic to your desire for less complexity and better
performance in passing security labels, from a kernel perspective I
think we lose too much in exporting the secid tokens outside the LSM.
To clarify, security identifiers were by design provided in the Flask
architecture and SELinux as lightweight, non-persistent handles to
security contexts, and exposed to userspace by the original SELinux API
(pre-2.6, of course). They were only removed when we transitioned to
using extended attributes and the xattr API for file security labels,
and we made all of the other APIs consistent as passing context strings
seemed acceptable for proc and selinuxfs as well. There was some
thought to turning SIDs into proper reference-counted objects or even
wrapping them with descriptors so that their lifecycles could be fully
managed by the kernel, but that never happened.
Passing a security context string on every binder IPC may be too costly
from a performance point of view (numbers would be helpful here). I
think this situation differs from that of stream sockets (i.e.
getsockopt SO_PEERSEC), since they are looking at enabling passing of
sender security label for every binder IPC (not just specific
applications) and since binder IPC is quite different from stream socket
IPC in its semantics and its performance.
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.
--
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
