> -----Original Message----- > From: owner-linux-security-mod...@vger.kernel.org [mailto:owner-linux- > security-mod...@vger.kernel.org] On Behalf Of Paul Moore > Sent: Friday, December 11, 2015 11:55 AM > To: Daniel Cashman <dcash...@android.com> > Cc: seli...@tycho.nsa.gov; Stephen Smalley <s...@tycho.nsa.gov>; Eric Paris > <epa...@parisplace.org>; James Morris <james.l.mor...@oracle.com>; > se...@hallyn.com; linux-security-module@vger.kernel.org; je...@google.com; > n...@google.com; a...@google.com > Subject: Re: Exposing secid to secctx mapping to user-space > > 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. >
I looked at doing the same thing a while back, and pretty much came to the same conclusion as Paul as mentioning here. I wanted to do this for sdcardd as part of the fuse struct. Since the security pointer is opaque outside of the LSM, it makes it difficult to transfer this information. However, could you just tag on something similar to how SO_PEERSEC works to the binder transaction? > -- > 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 N�����r��y����b�X��ǧv�^�){.n�+����{���.�+r��n�觶��ܨ}���Ơz�&j:+v�������zZ+��+zf���h���~����i���z� �w���?�����&�)ߢf
