Exposing secid to secctx mapping to user-space

Exposing secid to secctx mapping to user-space

[Daniel Cashman]

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.

Thank You,
Dan

Re: Exposing secid to secctx mapping to user-space

[Paul Moore]

On Fri, Dec 11, 2015 at 1:37 PM, Daniel Cashman <dcashman@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.

-- 
paul moore
www.paul-moore.com

RE: Exposing secid to secctx mapping to user-space

[Roberts, William C]

> -----Original Message-----
> From: owner-linux-security-module@vger.kernel.org [mailto:owner-linux-
> security-module@vger.kernel.org] On Behalf Of Paul Moore
> Sent: Friday, December 11, 2015 11:55 AM
> To: Daniel Cashman <dcashman@android.com>
> Cc: selinux@tycho.nsa.gov; Stephen Smalley <sds@tycho.nsa.gov>; Eric Paris
> <eparis@parisplace.org>; James Morris <james.l.morris@oracle.com>;
> serge@hallyn.com; linux-security-module@vger.kernel.org; jeffv@google.com;
> nnk@google.com; arve@google.com
> Subject: Re: Exposing secid to secctx mapping to user-space
> 
> On Fri, Dec 11, 2015 at 1:37 PM, Daniel Cashman <dcashman@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 majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

Re: Exposing secid to secctx mapping to user-space

[Stephen Smalley]

On 12/11/2015 02:55 PM, Paul Moore wrote:
> On Fri, Dec 11, 2015 at 1:37 PM, Daniel Cashman <dcashman@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.

Re: Exposing secid to secctx mapping to user-space

[Casey Schaufler]

On 12/11/2015 2:14 PM, Stephen Smalley wrote:
> On 12/11/2015 02:55 PM, Paul Moore wrote:
>> On Fri, Dec 11, 2015 at 1:37 PM, Daniel Cashman <dcashman@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.

It seems to me that a better approach might be for the object manager
to tell the binder driver about its security constraints and have the
binder driver do the check in the kernel. I realize that could require
additional LSM hooks (just like kdbus) but I think you may be looking
at that anyway, unless you're convinced binder will only ever work with
SELinux.

>
> 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.

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. You would always use the secalais in
binder communications. The advantage is that the kernel would know that
"#fish" was an alias for "Raygun_t:s27", just like the object manager.
The other, longer term, advantage is that when (if?) we get to extreme
module stacking we'll have a mechanism for dealing with a secctx like
<selinux="Raygun_t:s27"><smack="MyDoHasNoNose"><apparmor="specialcontext">.

security_secctx_to_secalias(), security_secalias_to_secctx().

There might be other kernel functions as well. I'd like to see the secalias
defined by the LSM infrastructure rather than each module, but I think we
could get agreement reasonably quickly. An eight character string beginning
with "#" as a strawman proposal.

/sys/fs/lsmfs/alais

	# echo 'Raygun_t:s27 #fish' > /sys/fs/lsmfs/alias

lsmfs would call security_alias_secctx(char *secctx, char *secalias)
to set the alais.

I suspect you could put it in the SELinux policy somehow, although
the kernel wouldn't care about it and could leave it up to the
user space to set it.

Just a Friday afternoon sort of thought.

> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Exposing secid to secctx mapping to user-space

[Paul Moore]

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

Re: Exposing secid to secctx mapping to user-space

[Mike Palmiotto]

On Sun, Dec 13, 2015 at 5:06 PM, Paul Moore <paul@paul-moore.com> 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@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

Re: Exposing secid to secctx mapping to user-space

[Casey Schaufler]

On 12/14/2015 9:03 AM, Mike Palmiotto wrote:
> On Sun, Dec 13, 2015 at 5:06 PM, Paul Moore <paul@paul-moore.com> 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.

If you need something persistent you can't use what the
kernel would provide, and if you don't you can make it up
on the fly. The binder case is different (and evil) because
the binder driver is letting user space make decisions on
behalf of the kernel.

>
> --Mike
>
>> --
>> paul moore
>> www.paul-moore.com
>>
>> _______________________________________________
>> Selinux mailing list
>> Selinux@tycho.nsa.gov
>> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

Re: Exposing secid to secctx mapping to user-space

[Stephen Smalley]

On 12/14/2015 12:03 PM, Mike Palmiotto wrote:
> On Sun, Dec 13, 2015 at 5:06 PM, Paul Moore <paul@paul-moore.com> 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.

The userspace AVC provides its own SID mapping (man avc_context_to_sid, 
avc_has_perm), but that mapping is process-local (unlike kernel SIDs, 
which are global) and non-persistent (like kernel SIDs, which also 
aren't guaranteed to remain stable across reboot).  That's what is 
conventionally used by userspace object managers like dbus-daemon, 
Xorg/XSELinux, and SE-Postgres (although IIRC SE-Postgres rolled their 
own custom AVC in order to optimize it specifically for their needs). 
Those SIDs can be used for in-core objects, but you still need to store 
the security context strings for persistent objects, although you can 
obviously store each unique one only once and maintain your own indices 
(ala the persistent SIDs of the Flask and original SELinux labeled 
filesystem implementation).

Re: Exposing secid to secctx mapping to user-space

[Casey Schaufler]

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.

RE: Exposing secid to secctx mapping to user-space

[Roberts, William C]

<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?

Re: Exposing secid to secctx mapping to user-space

[Stephen Smalley]

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().

Re: Exposing secid to secctx mapping to user-space

[William Roberts]

[-- Attachment #1: Type: text/plain, Size: 4422 bytes --]

On Mon, Dec 14, 2015 at 2:11 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:

> 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().


True, but in this case the binder transaction would be dead...

Why not just copy ctx?

grep -rn '^type ' * | grep domain | cut -d' ' -f 2-2 | sed s/','//g | awk '
{  thislen=length($0); printf("%-5s %dn", NR, thislen); totlen+=thislen}

END { printf("average: %dn", totlen/NR); } '

The avg type length for domain types in external/sepolicy is 7. Add the
full ctx:

u:r:xxxxxxx:s0(cat)

1. Were looking at like 18 or so bytes, how do we know this wont be "fast
enough"?
2. Whats the current perf numbers, and whats agreed upon on what you need
to hit to be fast enough?
3. Im assuming the use case is in service manager, but would a userspace
cache of AVD's help? Then you can (possibly) avoid both kernel trips, and
you can invalidate the cache on policy reload and on PID deaths? In the
case of service manager would it always be a miss based on usage patern? Im
assuming things would say hey resolve this once, and be done. However, you
could only do the ctx lookup and do the avd based on the policy in user
space, thus avoiding 1 of two trips.




>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to
> Selinux-request@tycho.nsa.gov.
>



-- 
Respectfully,

William C Roberts

[-- Attachment #2: Type: text/html, Size: 6933 bytes --]

RE: Exposing secid to secctx mapping to user-space

[Roberts, William C]

<snip>
> >
> > 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().
> 

I got a bounce from when I sent this from gmail, resending.

True, but in this case the binder transaction would be dead...

Why not just pass ctx? It's less than ideal, but it might be good enough for now until contexts get unwieldy big.

grep -rn '^type ' * | grep domain | cut -d' ' -f 2-2 | sed s/','//g | awk ' {  thislen=length($0); printf("%-5s %dn", NR, thislen); totlen+=thislen}                                     
END { printf("average: %dn", totlen/NR); } '

The avg type length for domain types in external/sepolicy is 7. Add the full ctx:

u:r:xxxxxxx:s0(cat)

1. We're looking at like 18 or so bytes, how do we know this won't be "fast enough"?
2. What's the current perf numbers, and what's agreed upon on what you need to hit to be fast enough?
3. I'm assuming the use case is in service manager, but would a userspace cache of AVD's help? Then you can (possibly) avoid both kernel trips, and you can invalidate the cache on policy reload and on PID deaths? In the case of service manager would it always be a miss based on usage pattern? I'm assuming things would say hey resolve this once, and be done. However, you could only do the ctx lookup and do the avd based on the policy in user space, thus avoiding 1 of two trips.

Re: Exposing secid to secctx mapping to user-space

[Stephen Smalley]

On 12/14/2015 05:57 PM, Roberts, William C wrote:
> <snip>
>>>
>>> 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().
>>
>
> I got a bounce from when I sent this from gmail, resending.
>
> True, but in this case the binder transaction would be dead...
>
> Why not just pass ctx? It's less than ideal, but it might be good enough for now until contexts get unwieldy big.
>
> grep -rn '^type ' * | grep domain | cut -d' ' -f 2-2 | sed s/','//g | awk ' {  thislen=length($0); printf("%-5s %dn", NR, thislen); totlen+=thislen}
> END { printf("average: %dn", totlen/NR); } '
>
> The avg type length for domain types in external/sepolicy is 7. Add the full ctx:
>
> u:r:xxxxxxx:s0(cat)
>
> 1. We're looking at like 18 or so bytes, how do we know this won't be "fast enough"?
> 2. What's the current perf numbers, and what's agreed upon on what you need to hit to be fast enough?
> 3. I'm assuming the use case is in service manager, but would a userspace cache of AVD's help? Then you can (possibly) avoid both kernel trips, and you can invalidate the cache on policy reload and on PID deaths? In the case of service manager would it always be a miss based on usage pattern? I'm assuming things would say hey resolve this once, and be done. However, you could only do the ctx lookup and do the avd based on the policy in user space, thus avoiding 1 of two trips.

1. I don't think it is the size of the context that is the concern but 
rather the fact that it is a variable-length string, whereas current 
binder commands use fixed-size arguments and encode the size in the 
command value (common for ioctls).  Supporting passing a variable-length 
string would be a change to the protocol and would complicate the code. 
  On the performance side, it means generating a context string from the 
secid and then copying it to userspace on each IPC (versus just getting 
the secid and putting that in the existing binder_transaction_data that 
is already copied to userspace).

2. Don't know; deferring to Daniel to run whatever binder IPC benchmarks 
might exist with and without the current patch that copies the context 
string.

3. It is for any binder-based service that wants to apply SELinux access 
checks, which presently includes servicemanager and keystore.
We already have a userspace AVC (in libselinux) that gets used 
automatically when you use selinux_check_access(), but you still need to 
get the sender security context in some manner.

Re: Exposing secid to secctx mapping to user-space

[Casey Schaufler]

On 12/15/2015 7:00 AM, Stephen Smalley wrote:
> On 12/14/2015 05:57 PM, Roberts, William C wrote:
>> <snip>
>>>>
>>>> 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().
>>>
>>
>> I got a bounce from when I sent this from gmail, resending.
>>
>> True, but in this case the binder transaction would be dead...
>>
>> Why not just pass ctx? It's less than ideal, but it might be good enough for now until contexts get unwieldy big.
>>
>> grep -rn '^type ' * | grep domain | cut -d' ' -f 2-2 | sed s/','//g | awk ' {  thislen=length($0); printf("%-5s %dn", NR, thislen); totlen+=thislen}
>> END { printf("average: %dn", totlen/NR); } '
>>
>> The avg type length for domain types in external/sepolicy is 7. Add the full ctx:
>>
>> u:r:xxxxxxx:s0(cat)
>>
>> 1. We're looking at like 18 or so bytes, how do we know this won't be "fast enough"?
>> 2. What's the current perf numbers, and what's agreed upon on what you need to hit to be fast enough?
>> 3. I'm assuming the use case is in service manager, but would a userspace cache of AVD's help? Then you can (possibly) avoid both kernel trips, and you can invalidate the cache on policy reload and on PID deaths? In the case of service manager would it always be a miss based on usage pattern? I'm assuming things would say hey resolve this once, and be done. However, you could only do the ctx lookup and do the avd based on the policy in user space, thus avoiding 1 of two trips.
>
> 1. I don't think it is the size of the context that is the concern but rather the fact that it is a variable-length string, whereas current binder commands use fixed-size arguments and encode the size in the command value (common for ioctls).  Supporting passing a variable-length string would be a change to the protocol and would complicate the code.  On the performance side, it means generating a context string from the secid and then copying it to userspace on each IPC (versus just getting the secid and putting that in the existing binder_transaction_data that is already copied to userspace).

I have long wondered why SELinux generates the context string
of the secid more than once. Audit performance alone would
justify keeping it around. The variable length issue isn't
so difficult as you make it out. As William pointed out earlier,
most SELinux contexts are short. Two protocols, one with a
fixed length of 16 chars (typical is 7) and one with a fixed
length of 256 (for abnormal contexts) solve the problem without
complicating the code hardly at all.

If it's such a problem, why do we have SO_PEERSEC return a
variable length string? That's been around forever and seems
to work just fine.

>
> 2. Don't know; deferring to Daniel to run whatever binder IPC benchmarks might exist with and without the current patch that copies the context string.
>
> 3. It is for any binder-based service that wants to apply SELinux access checks, which presently includes servicemanager and keystore.
> We already have a userspace AVC (in libselinux) that gets used automatically when you use selinux_check_access(), but you still need to get the sender security context in some manner.
>
>

Re: Exposing secid to secctx mapping to user-space

[Stephen Smalley]

On 12/15/2015 11:06 AM, Casey Schaufler wrote:
> On 12/15/2015 7:00 AM, Stephen Smalley wrote:
>> On 12/14/2015 05:57 PM, Roberts, William C wrote:
>>> <snip>
>>>>>
>>>>> 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().
>>>>
>>>
>>> I got a bounce from when I sent this from gmail, resending.
>>>
>>> True, but in this case the binder transaction would be dead...
>>>
>>> Why not just pass ctx? It's less than ideal, but it might be good enough for now until contexts get unwieldy big.
>>>
>>> grep -rn '^type ' * | grep domain | cut -d' ' -f 2-2 | sed s/','//g | awk ' {  thislen=length($0); printf("%-5s %dn", NR, thislen); totlen+=thislen}
>>> END { printf("average: %dn", totlen/NR); } '
>>>
>>> The avg type length for domain types in external/sepolicy is 7. Add the full ctx:
>>>
>>> u:r:xxxxxxx:s0(cat)
>>>
>>> 1. We're looking at like 18 or so bytes, how do we know this won't be "fast enough"?
>>> 2. What's the current perf numbers, and what's agreed upon on what you need to hit to be fast enough?
>>> 3. I'm assuming the use case is in service manager, but would a userspace cache of AVD's help? Then you can (possibly) avoid both kernel trips, and you can invalidate the cache on policy reload and on PID deaths? In the case of service manager would it always be a miss based on usage pattern? I'm assuming things would say hey resolve this once, and be done. However, you could only do the ctx lookup and do the avd based on the policy in user space, thus avoiding 1 of two trips.
>>
>> 1. I don't think it is the size of the context that is the concern but rather the fact that it is a variable-length string, whereas current binder commands use fixed-size arguments and encode the size in the command value (common for ioctls).  Supporting passing a variable-length string would be a change to the protocol and would complicate the code.  On the performance side, it means generating a context string from the secid and then copying it to userspace on each IPC (versus just getting the secid and putting that in the existing binder_transaction_data that is already copied to userspace).
>
> I have long wondered why SELinux generates the context string
> of the secid more than once. Audit performance alone would
> justify keeping it around. The variable length issue isn't
> so difficult as you make it out. As William pointed out earlier,
> most SELinux contexts are short. Two protocols, one with a
> fixed length of 16 chars (typical is 7) and one with a fixed
> length of 256 (for abnormal contexts) solve the problem without
> complicating the code hardly at all.
>
> If it's such a problem, why do we have SO_PEERSEC return a
> variable length string? That's been around forever and seems
> to work just fine.

Generating an audit record means you are already on the slow path, so 
adding the cost of generating a context at that point shouldn't be 
significant (but if one has performance data to the contrary, that would 
always be of interest). Keeping complete context strings in kernel 
memory at all times wasn't viewed as desirable, particularly when you 
consider the next point.

There is no internal limit on SELinux context size and one can in fact 
generate a SELinux context string that exceeds 256 bytes (just create a 
category set with many different, non-contiguous categories, e.g. a 
category set with every other category), so you can't just pick a couple 
of sizes (16 and 256 in your example) and be done with it.  It may be 
unusual to exceed 256 but it isn't impossible, and users of MLS systems 
have in fact run up against even the page size limitations of the 
/proc/self/attr interfaces as a pain point.

getsockopt SO_PEERSEC, as I mentioned earlier, is for stream sockets, so 
you are dealing with a connection-oriented model (with its attendant 
baseline overhead), server applications opt into getting the security 
label after the connection is established via getsockopt (which means 
that the overhead is not imposed on all connections, and which provides 
a straightforward way of passing variable-length data already), and all 
of the payload data is typically being copied through the kernel (to and 
from socket buffers).  With binder, we are talking about a synchronous 
IPC mechanism where the kernel copies the sender information (currently 
PID and UID) to the receiver on every IPC, the protocol currently passes 
no variable-length data, and the data is copied directly from the 
sender's memory into kernel-managed buffers that are mapped read-only 
into the receiver.  So introducing variable-length string copy to binder 
is a more substantial change, and the baseline performance 
characteristics and thus the relative overhead could differ.

In any event, I think we can wait for some performance data to show 
whether this is a real concern or not.

Re: Exposing secid to secctx mapping to user-space

[Casey Schaufler]

On 12/15/2015 8:55 AM, Stephen Smalley wrote:
> On 12/15/2015 11:06 AM, Casey Schaufler wrote:
>> On 12/15/2015 7:00 AM, Stephen Smalley wrote:
>>> On 12/14/2015 05:57 PM, Roberts, William C wrote:
>>>> <snip>
>>>>>>
>>>>>> 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().
>>>>>
>>>>
>>>> I got a bounce from when I sent this from gmail, resending.
>>>>
>>>> True, but in this case the binder transaction would be dead...
>>>>
>>>> Why not just pass ctx? It's less than ideal, but it might be good enough for now until contexts get unwieldy big.
>>>>
>>>> grep -rn '^type ' * | grep domain | cut -d' ' -f 2-2 | sed s/','//g | awk ' {  thislen=length($0); printf("%-5s %dn", NR, thislen); totlen+=thislen}
>>>> END { printf("average: %dn", totlen/NR); } '
>>>>
>>>> The avg type length for domain types in external/sepolicy is 7. Add the full ctx:
>>>>
>>>> u:r:xxxxxxx:s0(cat)
>>>>
>>>> 1. We're looking at like 18 or so bytes, how do we know this won't be "fast enough"?
>>>> 2. What's the current perf numbers, and what's agreed upon on what you need to hit to be fast enough?
>>>> 3. I'm assuming the use case is in service manager, but would a userspace cache of AVD's help? Then you can (possibly) avoid both kernel trips, and you can invalidate the cache on policy reload and on PID deaths? In the case of service manager would it always be a miss based on usage pattern? I'm assuming things would say hey resolve this once, and be done. However, you could only do the ctx lookup and do the avd based on the policy in user space, thus avoiding 1 of two trips.
>>>
>>> 1. I don't think it is the size of the context that is the concern but rather the fact that it is a variable-length string, whereas current binder commands use fixed-size arguments and encode the size in the command value (common for ioctls).  Supporting passing a variable-length string would be a change to the protocol and would complicate the code.  On the performance side, it means generating a context string from the secid and then copying it to userspace on each IPC (versus just getting the secid and putting that in the existing binder_transaction_data that is already copied to userspace).
>>
>> I have long wondered why SELinux generates the context string
>> of the secid more than once. Audit performance alone would
>> justify keeping it around. The variable length issue isn't
>> so difficult as you make it out. As William pointed out earlier,
>> most SELinux contexts are short. Two protocols, one with a
>> fixed length of 16 chars (typical is 7) and one with a fixed
>> length of 256 (for abnormal contexts) solve the problem without
>> complicating the code hardly at all.
>>
>> If it's such a problem, why do we have SO_PEERSEC return a
>> variable length string? That's been around forever and seems
>> to work just fine.
>
> Generating an audit record means you are already on the slow path, so adding the cost of generating a context at that point shouldn't be significant (but if one has performance data to the contrary, that would always be of interest). Keeping complete context strings in kernel memory at all times wasn't viewed as desirable, particularly when you consider the next point.

Making a slow path slower doesn't seem like a great idea to me.
The performance of audit is a major impediment to its use. There
are some cases where I can see regenerating the context on demand
as an optimization, but never in a case where the system regularly
exports them.

>
> There is no internal limit on SELinux context size and one can in fact generate a SELinux context string that exceeds 256 bytes (just create a category set with many different, non-contiguous categories, e.g. a category set with every other category), so you can't just pick a couple of sizes (16 and 256 in your example) and be done with it.  It may be unusual to exceed 256 but it isn't impossible, and users of MLS systems have in fact run up against even the page size limitations of the /proc/self/attr interfaces as a pain point.

My secalias suggestion could help here. :)

You're right. You'd still need an arbitrary size string protocol.
But I expect that binder using (i.e. Android) systems aren't going
wild with multiple category MLS (or MCS). Use of that protocol would
be sufficiently rare that finding non-artificial test cases would be
a challenge.

>
> getsockopt SO_PEERSEC, as I mentioned earlier, is for stream sockets, so you are dealing with a connection-oriented model (with its attendant baseline overhead), server applications opt into getting the security label after the connection is established via getsockopt (which means that the overhead is not imposed on all connections, and which provides a straightforward way of passing variable-length data already), and all of the payload data is typically being copied through the kernel (to and from socket buffers).  With binder, we are talking about a synchronous IPC mechanism where the kernel copies the sender information (currently PID and UID) to the receiver on every IPC, the protocol currently passes no variable-length data, and the data is copied directly from the sender's memory into kernel-managed buffers that are mapped read-only into the receiver.  So introducing variable-length string copy to binder is a more substantial change, and the baseline performance
> characteristics and thus the relative overhead could differ.

True, but I think that it's quite reasonable to optimize the common case
using a fixed16 + fixed256 + variable set of protocols. The common context
fits in 16 (make it 32 if you like), the odd case fits in 256, and the
extreme case, which probably never occurs on a binder based system, takes
the variable length hit.

>
> In any event, I think we can wait for some performance data to show whether this is a real concern or not.

I agree. I also think that it would be a grand idea to look into
keeping the secctx around rather than regenerating it as needed.
I can't help but think it would be a performance win, especially
with audit involved.

Re: Exposing secid to secctx mapping to user-space

[Joe Nall]

> On Dec 15, 2015, at 10:06 AM, Casey Schaufler <casey@schaufler-ca.com> wrote:
> 
> ...
> I have long wondered why SELinux generates the context string
> of the secid more than once. Audit performance alone would
> justify keeping it around. The variable length issue isn't
> so difficult as you make it out. As William pointed out earlier,
> most SELinux contexts are short. Two protocols, one with a
> fixed length of 16 chars (typical is 7) and one with a fixed
> length of 256 (for abnormal contexts) solve the problem without
> complicating the code hardly at all.

We have 'abnormal' contexts over 1024 bytes in production MLS systems. It is possible, though unlikely, to see raw contexts over 5k bytes with 1024 category bits. Thinking like this broke the original RHEL 5 racoon and more recently RHEL 6 openswan for us.

joe

system_u:system_r:silly_test_t:s2:c0,c2,c4,c6,c8,c10,c12,c14,c16,c18,c20,c22,c24,c26,c28,c30,c32,c34,c36,c38,c40,c42,c44,c46,c48,c50,c52,c54,c56,c58,c60,c62,c64,c66,c68,c70,c72,c74,c76,c78,c80,c82,c84,c86,c88,c90,c92,c94,c96,c98,c100,c102,c104,c106,c108,c110,c112,c114,c116,c118,c120,c122,c124,c126,c128,c130,c132,c134,c136,c138,c140,c142,c144,c146,c148,c150,c152,c154,c156,c158,c160,c162,c164,c166,c168,c170,c172,c174,c176,c178,c180,c182,c184,c186,c188,c190,c192,c194,c196,c198,c200,c202,c204,c206,c208,c210,c212,c214,c216,c218,c220,c222,c224,c226,c228,c230,c232,c234,c236,c238,c240,c242,c244,c246,c248,c250,c252,c254,c256,c258,c260,c262,c264,c266,c268,c270,c272,c274,c276,c278,c280,c282,c284,c286,c288,c290,c292,c294,c296,c298,c300,c302,c304,c306,c308,c310,c312,c314,c316,c318,c320,c322,c324,c326,c328,c330,c332,c334,c336,c338,c340,c342,c344,c346,c348,c350,c352,c354,c356,c358,c360,c362,c364,c366,c368,c370,c372,c374,c376,c378,c380,c382,c384,c386,c388,c390,c392,c394,c396,c398,c400,c402,c404,c406,c408,c410,c412,c414,c416,c418,c420,c422,c424,c426,c428,c430,c432,c434,c436,c438,c440,c442,c444,c446,c448,c450,c452,c454,c456,c458,c460,c462,c464,c466,c468,c470,c472,c474,c476,c478,c480,c482,c484,c486,c488,c490,c492,c494,c496,c498,c500,c502,c504,c506,c508,c510,c512,c514,c516,c518,c520,c522,c524,c526,c528,c530,c532,c534,c536,c538,c540,c542,c544,c546,c548,c550,c552,c554,c556,c558,c560,c562,c564,c566,c568,c570,c572,c574,c576,c578,c580,c582,c584,c586,c588,c590,c592,c594,c596,c598,c600,c602,c604,c606,c608,c610,c612,c614,c616,c618,c620,c622,c624,c626,c628,c630,c632,c634,c636,c638,c640,c642,c644,c646,c648,c650,c652,c654,c656,c658,c660,c662,c664,c666,c668,c670,c672,c674,c676,c678,c680,c682,c684,c686,c688,c690,c692,c694,c696,c698,c700,c702,c704,c706,c708,c710,c712,c714,c716,c718,c720,c722,c724,c726,c728,c730,c732,c734,c736,c738,c740,c742,c744,c746,c748,c750,c752,c754,c756,c758,c760,c762,c764,c766,c768,c770,c772,c774,c776,c778,c780,c782,c784,c786,c788,c790,c792,c794,c796,c798,c800,c802,c804,c806,c808,c810,c812,c814,c816,c818,c820,c822,c824,c826,c828,c830,c832,c834,c836,c838,c840,c842,c844,c846,c848,c850,c852,c854,c856,c858,c860,c862,c864,c866,c868,c870,c872,c874,c876,c878,c880,c882,c884,c886,c888,c890,c892,c894,c896,c898,c900,c902,c904,c906,c908,c910,c912,c914,c916,c918,c920,c922,c924,c926,c928,c930,c932,c934,c936,c938,c940,c942,c944,c946,c948,c950,c952,c954,c956,c958,c960,c962,c964,c966,c968,c970,c972,c974,c976,c978,c980,c982,c984,c986,c988,c990,c992,c994,c996,c998,c1000,c1002,c1004,c1006,c1008,c1010,c1012,c1014,c1016,c1018,c1020,c1022:s2:c0,c2,c4,c6,c8,c10,c12,c14,c16,c18,c20,c22,c24,c26,c28,c30,c32,c34,c36,c38,c40,c42,c44,c46,c48,c50,c52,c54,c56,c58,c60,c62,c64,c66,c68,c70,c72,c74,c76,c78,c80,c82,c84,c86,c88,c90,c92,c94,c96,c98,c100,c102,c104,c106,c108,c110,c112,c114,c116,c118,c120,c122,c124,c126,c128,c130,c132,c134,c136,c138,c140,c142,c144,c146,c148,c150,c152,c154,c156,c158,c160,c162,c164,c166,c168,c170,c172,c174,c176,c178,c180,c182,c184,c186,c188,c190,c192,c194,c196,c198,c200,c202,c204,c206,c208,c210,c212,c214,c216,c218,c220,c222,c224,c226,c228,c230,c232,c234,c236,c238,c240,c242,c244,c246,c248,c250,c252,c254,c256,c258,c260,c262,c264,c266,c268,c270,c272,c274,c276,c278,c280,c282,c284,c286,c288,c290,c292,c294,c296,c298,c300,c302,c304,c306,c308,c310,c312,c314,c316,c318,c320,c322,c324,c326,c328,c330,c332,c334,c336,c338,c340,c342,c344,c346,c348,c350,c352,c354,c356,c358,c360,c362,c364,c366,c368,c370,c372,c374,c376,c378,c380,c382,c384,c386,c388,c390,c392,c394,c396,c398,c400,c402,c404,c406,c408,c410,c412,c414,c416,c418,c420,c422,c424,c426,c428,c430,c432,c434,c436,c438,c440,c442,c444,c446,c448,c450,c452,c454,c456,c458,c460,c462,c464,c466,c468,c470,c472,c474,c476,c478,c480,c482,c484,c486,c488,c490,c492,c494,c496,c498,c500,c502,c504,c506,c508,c510,c512,c514,c516,c518,c520,c522,c524,c526,c528,c530,c532,c534,c536,c538,c540,c542,c544,c546,c548,c550,c552,c554,c556,c558,c560,c562,c564,c566,c568,c570,c572,c574,c576,c578,c580,c582,c584,c586,c588,c590,c592,c594,c596,c598,c600,c602,c604,c606,c608,c610,c612,c614,c616,c618,c620,c622,c624,c626,c628,c630,c632,c634,c636,c638,c640,c642,c644,c646,c648,c650,c652,c654,c656,c658,c660,c662,c664,c666,c668,c670,c672,c674,c676,c678,c680,c682,c684,c686,c688,c690,c692,c694,c696,c698,c700,c702,c704,c706,c708,c710,c712,c714,c716,c718,c720,c722,c724,c726,c728,c730,c732,c734,c736,c738,c740,c742,c744,c746,c748,c750,c752,c754,c756,c758,c760,c762,c764,c766,c768,c770,c772,c774,c776,c778,c780,c782,c784,c786,c788,c790,c792,c794,c796,c798,c800,c802,c804,c806,c808,c810,c812,c814,c816,c818,c820,c822,c824,c826,c828,c830,c832,c834,c836,c838,c840,c842,c844,c846,c848,c850,c852,c854,c856,c858,c860,c862,c864,c866,c868,c870,c872,c874,c876,c878,c880,c882,c884,c886,c888,c890,c892,c894,c896,c898,c900,c902,c904,c906,c908,c910,c912,c914,c916,c918,c920,c922,c924,c926,c928,c930,c932,c934,c936,c938,c940,c942,c944,c946,c948,c950,c952,c954,c956,c958,c960,c962,c964,c966,c968,c970,c972,c974,c976,c978,c980,c982,c984,c986,c988,c990,c992,c994,c996,c998,c1000,c1002,c1004,c1006,c1008,c1010,c1012,c1014,c1016,c1018,c1020.c1022

Re: Exposing secid to secctx mapping to user-space

[Stephen Smalley]

On 12/15/2015 12:19 PM, Joe Nall wrote:
>
>> On Dec 15, 2015, at 10:06 AM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>>
>> ...
>> I have long wondered why SELinux generates the context string
>> of the secid more than once. Audit performance alone would
>> justify keeping it around. The variable length issue isn't
>> so difficult as you make it out. As William pointed out earlier,
>> most SELinux contexts are short. Two protocols, one with a
>> fixed length of 16 chars (typical is 7) and one with a fixed
>> length of 256 (for abnormal contexts) solve the problem without
>> complicating the code hardly at all.
>
> We have 'abnormal' contexts over 1024 bytes in production MLS systems. It is possible, though unlikely, to see raw contexts over 5k bytes with 1024 category bits. Thinking like this broke the original RHEL 5 racoon and more recently RHEL 6 openswan for us.
>
> joe
>
> system_u:system_r:silly_test_t:s2:c0,c2,c4,c6,c8,c10,c12,c14,c16,c18,c20,c22,c24,c26,c28,c30,c32,c34,c36,c38,c40,c42,c44,c46,c48,c50,c52,c54,c56,c58,c60,c62,c64,c66,c68,c70,c72,c74,c76,c78,c80,c82,c84,c86,c88,c90,c92,c94,c96,c98,c100,c102,c104,c106,c108,c110,c112,c114,c116,c118,c120,c122,c124,c126,c128,c130,c132,c134,c136,c138,c140,c142,c144,c146,c148,c150,c152,c154,c156,c158,c160,c162,c164,c166,c168,c170,c172,c174,c176,c178,c180,c182,c184,c186,c188,c190,c192,c194,c196,c198,c200,c202,c204,c206,c208,c210,c212,c214,c216,c218,c220,c222,c224,c226,c228,c230,c232,c234,c236,c238,c240,c242,c244,c246,c248,c250,c252,c254,c256,c258,c260,c262,c264,c266,c268,c270,c272,c274,c276,c278,c280,c282,c284,c286,c288,c290,c292,c294,c296,c298,c300,c302,c304,c306,c308,c310,c312,c314,c316,c318,c320,c322,c324,c326,c328,c330,c332,c334,c336,c338,c340,c342,c344,c346,c348,c350,c352,c354,c356,c358,c360,c362,c364,c366,c368,c370,c372,c374,c376,c378,c380,c382,c384,c386,c388,c390,c392,c394,c396,c398,c400,c40!
 2,c404,c40
6,c408,c410,c412,c414,c416,c418,c420,c422,c424,c426,c428,c430,c432,c434,c436,c438,c440,c442,c444,c446,c448,c450,c452,c454,c456,c458,c460,c462,c464,c466,c468,c470,c472,c474,c476,c478,c480,c482,c484,c486,c488,c490,c492,c494,c496,c498,c500,c502,c504,c506,c508,c510,c512,c514,c516,c518,c520,c522,c524,c526,c528,c530,c532,c534,c536,c538,c540,c542,c544,c546,c548,c550,c552,c554,c556,c558,c560,c562,c564,c566,c568,c570,c572,c574,c576,c578,c580,c582,c584,c586,c588,c590,c592,c594,c596,c598,c600,c602,c604,c606,c608,c610,c612,c614,c616,c618,c620,c622,c624,c626,c628,c630,c632,c634,c636,c638,c640,c642,c644,c646,c648,c650,c652,c654,c656,c658,c660,c662,c664,c666,c668,c670,c672,c674,c676,c678,c680,c682,c684,c686,c688,c690,c692,c694,c696,c698,c700,c702,c704,c706,c708,c710,c712,c714,c716,c718,c720,c722,c724,c726,c728,c730,c732,c734,c736,c738,c740,c742,c744,c746,c748,c750,c752,c754,c756,c758,c760,c762,c764,c766,c768,c770,c772,c774,c776,c778,c780,c782,c784,c786,c788,c790,c792,c794,c796,c798,c800,c8!
 02,c804,c8
06,c808,c810,c812,c814,c816,c818,c820,c822,c824,c826,c828,c830,c832,c834,c836,c838,c840,c842,c844,c846,c848,c850,c852,c854,c856,c858,c860,c862,c864,c866,c868,c870,c872,c874,c876,c878,c880,c882,c884,c886,c888,c890,c892,c894,c896,c898,c900,c902,c904,c906,c908,c910,c912,c914,c916,c918,c920,c922,c924,c926,c928,c930,c932,c934,c936,c938,c940,c942,c944,c946,c948,c950,c952,c954,c956,c958,c960,c962,c964,c966,c968,c970,c972,c974,c976,c978,c980,c982,c984,c986,c988,c990,c992,c994,c996,c998,c1000,c1002,c1004,c1006,c1008,c1010,c1012,c1014,c1016,c1018,c1020,c1022:s2:c0,c2,c4,c6,c8,c10,c12,c14,c16,c18,c20,c22,c24,c26,c28,c30,c32,c34,c36,c38,c40,c42,c44,c46,c48,c50,c52,c54,c56,c58,c60,c62,c64,c66,c68,c70,c72,c74,c76,c78,c80,c82,c84,c86,c88,c90,c92,c94,c96,c98,c100,c102,c104,c106,c108,c110,c112,c114,c116,c118,c120,c122,c124,c126,c128,c130,c132,c134,c136,c138,c140,c142,c144,c146,c148,c150,c152,c154,c156,c158,c160,c162,c164,c166,c168,c170,c172,c174,c176,c178,c180,c182,c184,c186,c188,c190,c192,c!
 194,c196,c
198,c200,c202,c204,c206,c208,c210,c212,c214,c216,c218,c220,c222,c224,c226,c228,c230,c232,c234,c236,c238,c240,c242,c244,c246,c248,c250,c252,c254,c256,c258,c260,c262,c264,c266,c268,c270,c272,c274,c276,c278,c280,c282,c284,c286,c288,c290,c292,c294,c296,c298,c300,c302,c304,c306,c308,c310,c312,c314,c316,c318,c320,c322,c324,c326,c328,c330,c332,c334,c336,c338,c340,c342,c344,c346,c348,c350,c352,c354,c356,c358,c360,c362,c364,c366,c368,c370,c372,c374,c376,c378,c380,c382,c384,c386,c388,c390,c392,c394,c396,c398,c400,c402,c404,c406,c408,c410,c412,c414,c416,c418,c420,c422,c424,c426,c428,c430,c432,c434,c436,c438,c440,c442,c444,c446,c448,c450,c452,c454,c456,c458,c460,c462,c464,c466,c468,c470,c472,c474,c476,c478,c480,c482,c484,c486,c488,c490,c492,c494,c496,c498,c500,c502,c504,c506,c508,c510,c512,c514,c516,c518,c520,c522,c524,c526,c528,c530,c532,c534,c536,c538,c540,c542,c544,c546,c548,c550,c552,c554,c556,c558,c560,c562,c564,c566,c568,c570,c572,c574,c576,c578,c580,c582,c584,c586,c588,c590,c592,!
 c594,c596,
c598,c600,c602,c604,c606,c608,c610,c612,c614,c616,c618,c620,c622,c624,c626,c628,c630,c632,c634,c636,c638,c640,c642,c644,c646,c648,c650,c652,c654,c656,c658,c660,c662,c664,c666,c668,c670,c672,c674,c676,c678,c680,c682,c684,c686,c688,c690,c692,c694,c696,c698,c700,c702,c704,c706,c708,c710,c712,c714,c716,c718,c720,c722,c724,c726,c728,c730,c732,c734,c736,c738,c740,c742,c744,c746,c748,c750,c752,c754,c756,c758,c760,c762,c764,c766,c768,c770,c772,c774,c776,c778,c780,c782,c784,c786,c788,c790,c792,c794,c796,c798,c800,c802,c804,c806,c808,c810,c812,c814,c816,c818,c820,c822,c824,c826,c828,c830,c832,c834,c836,c838,c840,c842,c844,c846,c848,c850,c852,c854,c856,c858,c860,c862,c864,c866,c868,c870,c872,c874,c876,c878,c880,c882,c884,c886,c888,c890,c892,c894,c896,c898,c900,c902,c904,c906,c908,c910,c912,c914,c916,c918,c920,c922,c924,c926,c928,c930,c932,c934,c936,c938,c940,c942,c944,c946,c948,c950,c952,c954,c956,c958,c960,c962,c964,c966,c968,c970,c972,c974,c976,c978,c980,c982,c984,c986,c988,c990,c992!
 ,c994,c996
,c998,c1000,c1002,c1004,c1006,c1008,c1010,c1012,c1014,c1016,c1018,c1020.c1022

Are you patching the kernel to support > 4K contexts?
Otherwise, I'd expect you run up against the proc and selinuxfs API 
limitations (page size) and/or the filesystem xattr storage limitations 
(block size).

Re: Exposing secid to secctx mapping to user-space

[Joe Nall]

> On Dec 15, 2015, at 12:03 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> 
> On 12/15/2015 12:19 PM, Joe Nall wrote:
>> 
>>> On Dec 15, 2015, at 10:06 AM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>>> 
>>> ...
>>> I have long wondered why SELinux generates the context string
>>> of the secid more than once. Audit performance alone would
>>> justify keeping it around. The variable length issue isn't
>>> so difficult as you make it out. As William pointed out earlier,
>>> most SELinux contexts are short. Two protocols, one with a
>>> fixed length of 16 chars (typical is 7) and one with a fixed
>>> length of 256 (for abnormal contexts) solve the problem without
>>> complicating the code hardly at all.
>> 
>> We have 'abnormal' contexts over 1024 bytes in production MLS systems. It is possible, though unlikely, to see raw contexts over 5k bytes with 1024 category bits. Thinking like this broke the original RHEL 5 racoon and more recently RHEL 6 openswan for us.
>> 
>> joe
>> 
>> system_u:system_r:silly_test_t:s2:c0,c2,c4,c6,c8,c10,c12,c14,c16,c18,c20,c22,c24,c26,c28,c30,c32,c34,c36,c38,c40,c42,c44,c46,c48,c50,c52,c54,c56,c58,c60,c62,c64,c66,c68,c70,c72,c74,c76,c78,c80,c82,c84,c86,c88,c90,c92,c94,c96,c98,c100,c102,c104,c106,c108,c110,c112,c114,c116,c118,c120,c122,c124,c126,c128,c130,c132,c134,c136,c138,c140,c142,c144,c146,c148,c150,c152,c154,c156,c158,c160,c162,c164,c166,c168,c170,c172,c174,c176,c178,c180,c182,c184,c186,c188,c190,c192,c194,c196,c198,c200,c202,c204,c206,c208,c210,c212,c214,c216,c218,c220,c222,c224,c226,c228,c230,c232,c234,c236,c238,c240,c242,c244,c246,c248,c250,c252,c254,c256,c258,c260,c262,c264,c266,c268,c270,c272,c274,c276,c278,c280,c282,c284,c286,c288,c290,c292,c294,c296,c298,c300,c302,c304,c306,c308,c310,c312,c314,c316,c318,c320,c322,c324,c326,c328,c330,c332,c334,c336,c338,c340,c342,c344,c346,c348,c350,c352,c354,c356,c358,c360,c362,c364,c366,c368,c370,c372,c374,c376,c378,c380,c382,c384,c386,c388,c390,c392,c394,c396,c398,c400,c402,c404,c40
> 6,c408,c410,c412,c414,c416,c418,c420,c422,c424,c426,c428,c430,c432,c434,c436,c438,c440,c442,c444,c446,c448,c450,c452,c454,c456,c458,c460,c462,c464,c466,c468,c470,c472,c474,c476,c478,c480,c482,c484,c486,c488,c490,c492,c494,c496,c498,c500,c502,c504,c506,c508,c510,c512,c514,c516,c518,c520,c522,c524,c526,c528,c530,c532,c534,c536,c538,c540,c542,c544,c546,c548,c550,c552,c554,c556,c558,c560,c562,c564,c566,c568,c570,c572,c574,c576,c578,c580,c582,c584,c586,c588,c590,c592,c594,c596,c598,c600,c602,c604,c606,c608,c610,c612,c614,c616,c618,c620,c622,c624,c626,c628,c630,c632,c634,c636,c638,c640,c642,c644,c646,c648,c650,c652,c654,c656,c658,c660,c662,c664,c666,c668,c670,c672,c674,c676,c678,c680,c682,c684,c686,c688,c690,c692,c694,c696,c698,c700,c702,c704,c706,c708,c710,c712,c714,c716,c718,c720,c722,c724,c726,c728,c730,c732,c734,c736,c738,c740,c742,c744,c746,c748,c750,c752,c754,c756,c758,c760,c762,c764,c766,c768,c770,c772,c774,c776,c778,c780,c782,c784,c786,c788,c790,c792,c794,c796,c798,c800,c802,c804,c8
> 06,c808,c810,c812,c814,c816,c818,c820,c822,c824,c826,c828,c830,c832,c834,c836,c838,c840,c842,c844,c846,c848,c850,c852,c854,c856,c858,c860,c862,c864,c866,c868,c870,c872,c874,c876,c878,c880,c882,c884,c886,c888,c890,c892,c894,c896,c898,c900,c902,c904,c906,c908,c910,c912,c914,c916,c918,c920,c922,c924,c926,c928,c930,c932,c934,c936,c938,c940,c942,c944,c946,c948,c950,c952,c954,c956,c958,c960,c962,c964,c966,c968,c970,c972,c974,c976,c978,c980,c982,c984,c986,c988,c990,c992,c994,c996,c998,c1000,c1002,c1004,c1006,c1008,c1010,c1012,c1014,c1016,c1018,c1020,c1022:s2:c0,c2,c4,c6,c8,c10,c12,c14,c16,c18,c20,c22,c24,c26,c28,c30,c32,c34,c36,c38,c40,c42,c44,c46,c48,c50,c52,c54,c56,c58,c60,c62,c64,c66,c68,c70,c72,c74,c76,c78,c80,c82,c84,c86,c88,c90,c92,c94,c96,c98,c100,c102,c104,c106,c108,c110,c112,c114,c116,c118,c120,c122,c124,c126,c128,c130,c132,c134,c136,c138,c140,c142,c144,c146,c148,c150,c152,c154,c156,c158,c160,c162,c164,c166,c168,c170,c172,c174,c176,c178,c180,c182,c184,c186,c188,c190,c192,c194,c196,c
> 198,c200,c202,c204,c206,c208,c210,c212,c214,c216,c218,c220,c222,c224,c226,c228,c230,c232,c234,c236,c238,c240,c242,c244,c246,c248,c250,c252,c254,c256,c258,c260,c262,c264,c266,c268,c270,c272,c274,c276,c278,c280,c282,c284,c286,c288,c290,c292,c294,c296,c298,c300,c302,c304,c306,c308,c310,c312,c314,c316,c318,c320,c322,c324,c326,c328,c330,c332,c334,c336,c338,c340,c342,c344,c346,c348,c350,c352,c354,c356,c358,c360,c362,c364,c366,c368,c370,c372,c374,c376,c378,c380,c382,c384,c386,c388,c390,c392,c394,c396,c398,c400,c402,c404,c406,c408,c410,c412,c414,c416,c418,c420,c422,c424,c426,c428,c430,c432,c434,c436,c438,c440,c442,c444,c446,c448,c450,c452,c454,c456,c458,c460,c462,c464,c466,c468,c470,c472,c474,c476,c478,c480,c482,c484,c486,c488,c490,c492,c494,c496,c498,c500,c502,c504,c506,c508,c510,c512,c514,c516,c518,c520,c522,c524,c526,c528,c530,c532,c534,c536,c538,c540,c542,c544,c546,c548,c550,c552,c554,c556,c558,c560,c562,c564,c566,c568,c570,c572,c574,c576,c578,c580,c582,c584,c586,c588,c590,c592,c594,c596,
> c598,c600,c602,c604,c606,c608,c610,c612,c614,c616,c618,c620,c622,c624,c626,c628,c630,c632,c634,c636,c638,c640,c642,c644,c646,c648,c650,c652,c654,c656,c658,c660,c662,c664,c666,c668,c670,c672,c674,c676,c678,c680,c682,c684,c686,c688,c690,c692,c694,c696,c698,c700,c702,c704,c706,c708,c710,c712,c714,c716,c718,c720,c722,c724,c726,c728,c730,c732,c734,c736,c738,c740,c742,c744,c746,c748,c750,c752,c754,c756,c758,c760,c762,c764,c766,c768,c770,c772,c774,c776,c778,c780,c782,c784,c786,c788,c790,c792,c794,c796,c798,c800,c802,c804,c806,c808,c810,c812,c814,c816,c818,c820,c822,c824,c826,c828,c830,c832,c834,c836,c838,c840,c842,c844,c846,c848,c850,c852,c854,c856,c858,c860,c862,c864,c866,c868,c870,c872,c874,c876,c878,c880,c882,c884,c886,c888,c890,c892,c894,c896,c898,c900,c902,c904,c906,c908,c910,c912,c914,c916,c918,c920,c922,c924,c926,c928,c930,c932,c934,c936,c938,c940,c942,c944,c946,c948,c950,c952,c954,c956,c958,c960,c962,c964,c966,c968,c970,c972,c974,c976,c978,c980,c982,c984,c986,c988,c990,c992,c994,c996
> ,c998,c1000,c1002,c1004,c1006,c1008,c1010,c1012,c1014,c1016,c1018,c1020.c1022
> 
> Are you patching the kernel to support > 4K contexts?
> Otherwise, I'd expect you run up against the proc and selinuxfs API limitations (page size) and/or the filesystem xattr storage limitations (block size).

No. The example was a contrived example of what is possible within the format. We use a couple of 2500 byte labels in formal test these days to make sure that we don't have an OS regression. I just get tired of code like this in openswan:

#ifdef HAVE_LABELED_IPSEC
/* security label length should not exceed 256 in most cases,
 * (discussed with kernel and selinux people).
 */
#define MAX_SECCTX_LEN    257 /* including '\0'*/

joe

Re: Exposing secid to secctx mapping to user-space

[Paul Moore]

On Tue, Dec 15, 2015 at 2:09 PM, Joe Nall <joe@nall.com> wrote:
>> On Dec 15, 2015, at 12:03 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> Are you patching the kernel to support > 4K contexts?
>> Otherwise, I'd expect you run up against the proc and selinuxfs API limitations (page size) and/or the filesystem xattr storage limitations (block size).
>
> No. The example was a contrived example of what is possible within the format. We use a couple of 2500 byte labels in formal test these days to make sure that we don't have an OS regression. I just get tired of code like this in openswan:
>
> #ifdef HAVE_LABELED_IPSEC
> /* security label length should not exceed 256 in most cases,
>  * (discussed with kernel and selinux people).
>  */
> #define MAX_SECCTX_LEN    257 /* including '\0'*/

So let's just get rid of labeled IPsec ... show of hands? ;)

-- 
paul moore
www.paul-moore.com

Re: Exposing secid to secctx mapping to user-space

[Daniel Cashman]

On 12/15/2015 07:00 AM, Stephen Smalley wrote:
> On 12/14/2015 05:57 PM, Roberts, William C wrote:
>> <snip>
>>>>
>>>> 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().
>>>
>>
>> I got a bounce from when I sent this from gmail, resending.
>>
>> True, but in this case the binder transaction would be dead...
>>
>> Why not just pass ctx? It's less than ideal, but it might be good
>> enough for now until contexts get unwieldy big.
>>
>> grep -rn '^type ' * | grep domain | cut -d' ' -f 2-2 | sed s/','//g |
>> awk ' {  thislen=length($0); printf("%-5s %dn", NR, thislen);
>> totlen+=thislen}
>> END { printf("average: %dn", totlen/NR); } '
>>
>> The avg type length for domain types in external/sepolicy is 7. Add
>> the full ctx:
>>
>> u:r:xxxxxxx:s0(cat)
>>
>> 1. We're looking at like 18 or so bytes, how do we know this won't be
>> "fast enough"?
>> 2. What's the current perf numbers, and what's agreed upon on what you
>> need to hit to be fast enough?
>> 3. I'm assuming the use case is in service manager, but would a
>> userspace cache of AVD's help? Then you can (possibly) avoid both
>> kernel trips, and you can invalidate the cache on policy reload and on
>> PID deaths? In the case of service manager would it always be a miss
>> based on usage pattern? I'm assuming things would say hey resolve this
>> once, and be done. However, you could only do the ctx lookup and do
>> the avd based on the policy in user space, thus avoiding 1 of two trips.
> 
> 1. I don't think it is the size of the context that is the concern but
> rather the fact that it is a variable-length string, whereas current
> binder commands use fixed-size arguments and encode the size in the
> command value (common for ioctls).  Supporting passing a variable-length
> string would be a change to the protocol and would complicate the code.
>  On the performance side, it means generating a context string from the
> secid and then copying it to userspace on each IPC (versus just getting
> the secid and putting that in the existing binder_transaction_data that
> is already copied to userspace).

This is precisely the motivation for the original enquiry. Issue has
been brought up about changing the protocol, and concern has also been
strongly expressed about the overhead introduced by the string
operations, although this has not been measured.  User-space would still
need to do something intelligent with the secid, which would involve its
own lookup and caching, but the idea is that this wouldn't be done with
the binder lock held.

> 2. Don't know; deferring to Daniel to run whatever binder IPC benchmarks
> might exist with and without the current patch that copies the context
> string.

Yes, this needs to be done.  This issue was brought up as part of
discussion regarding a proposed change to the binder driver to add the
context string to each transaction.  An outcome of that discussion was,
"before we go too far into this, let's see the reaction upstream to
exposing the secid."  Based on the reaction here (upstream), I think
it's my responsibility to push forward the string-based change and get
the appropriate perf numbers so that a meaningful comparison can be made.

> 3. It is for any binder-based service that wants to apply SELinux access
> checks, which presently includes servicemanager and keystore.
> We already have a userspace AVC (in libselinux) that gets used
> automatically when you use selinux_check_access(), but you still need to
> get the sender security context in some manner.
> 

The issue this hopes to address is passing the secctx along with a
binder transaction so that userspace can use it for any access
appropriate access controls.  Specifically, at the moment, I'm hoping to
use the receiving process's concept of which service is being invoked
and what the transaction code represents (neither of which the binder
driver itself has any concept) to create an SELinux object manager that
filters service method calls.  This could be seen as a more general
implementation of the keystore service object manager.

The getpidcon() and  SO_PEERSEC type solutions are, as Stephen pointed
out, racy such that a process could have changed its context in the
interim, but also such that they do not address one-way binder
transactions, in which a process could fire of a request and die before
it gets processed.  This isn't an issue for the servicemanager's current
object manager, but could be an issue for other services.

Thank You,
Dan

Re: Exposing secid to secctx mapping to user-space

[William Roberts]

[-- Attachment #1: Type: text/plain, Size: 6213 bytes --]

On Tue, Dec 15, 2015 at 12:58 PM, Daniel Cashman <dcashman@android.com>
wrote:

> On 12/15/2015 07:00 AM, Stephen Smalley wrote:
> > On 12/14/2015 05:57 PM, Roberts, William C wrote:
> >> <snip>
> >>>>
> >>>> 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().
> >>>
> >>
> >> I got a bounce from when I sent this from gmail, resending.
> >>
> >> True, but in this case the binder transaction would be dead...
> >>
> >> Why not just pass ctx? It's less than ideal, but it might be good
> >> enough for now until contexts get unwieldy big.
> >>
> >> grep -rn '^type ' * | grep domain | cut -d' ' -f 2-2 | sed s/','//g |
> >> awk ' {  thislen=length($0); printf("%-5s %dn", NR, thislen);
> >> totlen+=thislen}
> >> END { printf("average: %dn", totlen/NR); } '
> >>
> >> The avg type length for domain types in external/sepolicy is 7. Add
> >> the full ctx:
> >>
> >> u:r:xxxxxxx:s0(cat)
> >>
> >> 1. We're looking at like 18 or so bytes, how do we know this won't be
> >> "fast enough"?
> >> 2. What's the current perf numbers, and what's agreed upon on what you
> >> need to hit to be fast enough?
> >> 3. I'm assuming the use case is in service manager, but would a
> >> userspace cache of AVD's help? Then you can (possibly) avoid both
> >> kernel trips, and you can invalidate the cache on policy reload and on
> >> PID deaths? In the case of service manager would it always be a miss
> >> based on usage pattern? I'm assuming things would say hey resolve this
> >> once, and be done. However, you could only do the ctx lookup and do
> >> the avd based on the policy in user space, thus avoiding 1 of two trips.
> >
> > 1. I don't think it is the size of the context that is the concern but
> > rather the fact that it is a variable-length string, whereas current
> > binder commands use fixed-size arguments and encode the size in the
> > command value (common for ioctls).  Supporting passing a variable-length
> > string would be a change to the protocol and would complicate the code.
> >  On the performance side, it means generating a context string from the
> > secid and then copying it to userspace on each IPC (versus just getting
> > the secid and putting that in the existing binder_transaction_data that
> > is already copied to userspace).
>
> This is precisely the motivation for the original enquiry. Issue has
> been brought up about changing the protocol, and concern has also been
> strongly expressed about the overhead introduced by the string
> operations, although this has not been measured.  User-space would still
> need to do something intelligent with the secid, which would involve its
> own lookup and caching, but the idea is that this wouldn't be done with
> the binder lock held.
>
> > 2. Don't know; deferring to Daniel to run whatever binder IPC benchmarks
> > might exist with and without the current patch that copies the context
> > string.
>
> Yes, this needs to be done.  This issue was brought up as part of
> discussion regarding a proposed change to the binder driver to add the
> context string to each transaction.  An outcome of that discussion was,
> "before we go too far into this, let's see the reaction upstream to
> exposing the secid."  Based on the reaction here (upstream), I think
> it's my responsibility to push forward the string-based change and get
> the appropriate perf numbers so that a meaningful comparison can be made.
>
> > 3. It is for any binder-based service that wants to apply SELinux access
> > checks, which presently includes servicemanager and keystore.
> > We already have a userspace AVC (in libselinux) that gets used
> > automatically when you use selinux_check_access(), but you still need to
> > get the sender security context in some manner.
> >
>
> The issue this hopes to address is passing the secctx along with a
> binder transaction so that userspace can use it for any access
> appropriate access controls.  Specifically, at the moment, I'm hoping to
> use the receiving process's concept of which service is being invoked
> and what the transaction code represents (neither of which the binder
> driver itself has any concept) to create an SELinux object manager that
> filters service method calls.  This could be seen as a more general
> implementation of the keystore service object manager.
>

Doing this in a general fashion that is enumerable per LSM, for stacking
support,
and making it simple so others can use it. This would be great to have in
FUSE.
I've been looking on and off for awhile of adding controls to sdcardd, and
not
having getpidcon() calls would be nice. I also went down the seccid approach
initially, but moved away from it.


>
> The getpidcon() and  SO_PEERSEC type solutions are, as Stephen pointed
> out, racy such that a process could have changed its context in the
> interim, but also such that they do not address one-way binder
> transactions, in which a process could fire of a request and die before
> it gets processed.  This isn't an issue for the servicemanager's current
> object manager, but could be an issue for other services.
>

Yes the pid is racy, but for things like binder or fuse, the peer would be
dead, however
could be an issue for others (as you mentioned).

It would be interesting if you could register your service into the kernel
portion of binder with
a context, then the look up and enforcement would be soley in the kernel,
but isn't this ala
kdbus (I am so ignorant to kdbus so I might be way off)


> Thank You,
> Dan
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to
> Selinux-request@tycho.nsa.gov.
>



-- 
Respectfully,

William C Roberts

[-- Attachment #2: Type: text/html, Size: 8124 bytes --]

Re: Exposing secid to secctx mapping to user-space

[Paul Moore]

On Tue, Dec 15, 2015 at 3:58 PM, Daniel Cashman <dcashman@android.com> wrote:
> On 12/15/2015 07:00 AM, Stephen Smalley wrote:
>> 1. I don't think it is the size of the context that is the concern but
>> rather the fact that it is a variable-length string, whereas current
>> binder commands use fixed-size arguments and encode the size in the
>> command value (common for ioctls).  Supporting passing a variable-length
>> string would be a change to the protocol and would complicate the code.
>>  On the performance side, it means generating a context string from the
>> secid and then copying it to userspace on each IPC (versus just getting
>> the secid and putting that in the existing binder_transaction_data that
>> is already copied to userspace).
>
> This is precisely the motivation for the original enquiry. Issue has
> been brought up about changing the protocol, and concern has also been
> strongly expressed about the overhead introduced by the string
> operations, although this has not been measured.  User-space would still
> need to do something intelligent with the secid, which would involve its
> own lookup and caching, but the idea is that this wouldn't be done with
> the binder lock held.
>
>> 2. Don't know; deferring to Daniel to run whatever binder IPC benchmarks
>> might exist with and without the current patch that copies the context
>> string.
>
> Yes, this needs to be done.  This issue was brought up as part of
> discussion regarding a proposed change to the binder driver to add the
> context string to each transaction.  An outcome of that discussion was,
> "before we go too far into this, let's see the reaction upstream to
> exposing the secid."  Based on the reaction here (upstream), I think
> it's my responsibility to push forward the string-based change and get
> the appropriate perf numbers so that a meaningful comparison can be made.

The existing, variable length string based approach is going to be
your easiest path forward with respect to the kernel, although it may
turn out to be a non-starter from a binder point of view.  I just want
to reiterate that I'm not against the idea of exposing the secid
tokens, but not necessarily in their current form; we will probably
want to revisit the idea of a persistent secid and consider the impact
to any future stacking work.

-- 
paul moore
www.paul-moore.com

Re: Exposing secid to secctx mapping to user-space

[Casey Schaufler]

On 12/11/2015 10:37 AM, Daniel Cashman 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.

Please abandon this.

> 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.

The security module infrastructure makes no guarantees about
secids. A security module is not required to maintain a persistent
relationship between the secid and a particular secctx. SELinux
does maintain a persistent relationship, but I don't believe that
there is any desire to commit to everything associated with exposing
that.

Binder ought to have access to more than the secid of the processes
and objects involved. Look into the possibilities there before you
take this approach.

>
> Thank You,
> Dan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>