What did I do wrong?

What did I do wrong?

[Minear, Spencer]

Wonder if someone could give me a pointer to what my policy file is missing that would result in the /sys/fs/selinux/user API not providing a context when the sshd process context is written to that API?  I can see the behavior in a strace capture.  I believe that the action is  a call from sshd to the security_compute_user entry in libselinux.

On a clean working system with the available default policy sshd writes in the sshd process's context and reads back the context that is ultimately applied to the shell process started by sshd.

Obviously I'm missing something or not including some critical information into the policy but I haven't been able to find any documentation that describes what goes on behind the scenes of this API.

Spence Minear

 

Re: What did I do wrong?

[Stephen Smalley]

On 01/20/2015 11:28 PM, Minear, Spencer wrote:
> Wonder if someone could give me a pointer to what my policy file is missing that would result in the /sys/fs/selinux/user API not providing a context when the sshd process context is written to that API?  I can see the behavior in a strace capture.  I believe that the action is  a call from sshd to the security_compute_user entry in libselinux.
> 
> On a clean working system with the available default policy sshd writes in the sshd process's context and reads back the context that is ultimately applied to the shell process started by sshd.
> 
> Obviously I'm missing something or not including some critical information into the policy but I haven't been able to find any documentation that describes what goes on behind the scenes of this API.

Did the write() to /sys/fs/selinux/user return an error code (if so,
what errno), or a string specifying that there are 0 contexts?

The underlying function first computes the maximal set of possible
contexts based on the user's role authorizations and the role's type
authorizations in the policy.  Then it filters that set to only include
contexts for which process transition permission is allowed in policy
from the caller's context (i.e. sshd in this case).

There is some further complication for the MLS field; it prefers the
user's default level from the policy if that falls within the range of
the caller's MLS range.  But if the user's default level is not within
that range, it tries to find a level that is both consistent with the
caller's MLS range limitations and the user's authorized range.  If it
cannot do so, it will ultimately fail with an error.

This has long been on our todo as something to take to userspace and
simplify.

RE: What did I do wrong?

[Minear, Spencer]

The write to /sys/fs/selinux/user was successful.  The read was successful too, but returned only "0\0".  The read return value was 2, which matches what I see coming back.  This makes me think that I am missing some information in the policy that leads to what appears to be an unexpected result rather than one or more new context's that I believe that the interface is supposed to return.

Spence

-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
Sent: Wednesday, January 21, 2015 7:42 AM
To: Minear, Spencer; SELinux (selinux@tycho.nsa.gov)
Subject: Re: What did I do wrong?

On 01/20/2015 11:28 PM, Minear, Spencer wrote:
> Wonder if someone could give me a pointer to what my policy file is missing that would result in the /sys/fs/selinux/user API not providing a context when the sshd process context is written to that API?  I can see the behavior in a strace capture.  I believe that the action is  a call from sshd to the security_compute_user entry in libselinux.
> 
> On a clean working system with the available default policy sshd writes in the sshd process's context and reads back the context that is ultimately applied to the shell process started by sshd.
> 
> Obviously I'm missing something or not including some critical information into the policy but I haven't been able to find any documentation that describes what goes on behind the scenes of this API.

Did the write() to /sys/fs/selinux/user return an error code (if so, what errno), or a string specifying that there are 0 contexts?

The underlying function first computes the maximal set of possible contexts based on the user's role authorizations and the role's type authorizations in the policy.  Then it filters that set to only include contexts for which process transition permission is allowed in policy from the caller's context (i.e. sshd in this case).

There is some further complication for the MLS field; it prefers the user's default level from the policy if that falls within the range of the caller's MLS range.  But if the user's default level is not within that range, it tries to find a level that is both consistent with the caller's MLS range limitations and the user's authorized range.  If it cannot do so, it will ultimately fail with an error.

This has long been on our todo as something to take to userspace and simplify.

Re: What did I do wrong?

[Stephen Smalley]

On 01/21/2015 09:18 AM, Minear, Spencer wrote:
> The write to /sys/fs/selinux/user was successful.  The read was successful too, but returned only "0\0".  The read return value was 2, which matches what I see coming back.  This makes me think that I am missing some information in the policy that leads to what appears to be an unexpected result rather than one or more new context's that I believe that the interface is supposed to return.

The response buffer (i.e. what you read from /sys/fs/selinux/user)
begins with a count of the number of contexts, followed by a NUL,
followed by the list of contexts, NUL-separated.  So in this case, the
response is saying that it couldn't find any reachable contexts for that
user from the calling context (whatever sshd is running in) under the
loaded policy.  So, yes, check your user-role authorizations, your
role-type authorizations, and transition permission from sshd's context.

> 
> Spence
> 
> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
> Sent: Wednesday, January 21, 2015 7:42 AM
> To: Minear, Spencer; SELinux (selinux@tycho.nsa.gov)
> Subject: Re: What did I do wrong?
> 
> On 01/20/2015 11:28 PM, Minear, Spencer wrote:
>> Wonder if someone could give me a pointer to what my policy file is missing that would result in the /sys/fs/selinux/user API not providing a context when the sshd process context is written to that API?  I can see the behavior in a strace capture.  I believe that the action is  a call from sshd to the security_compute_user entry in libselinux.
>>
>> On a clean working system with the available default policy sshd writes in the sshd process's context and reads back the context that is ultimately applied to the shell process started by sshd.
>>
>> Obviously I'm missing something or not including some critical information into the policy but I haven't been able to find any documentation that describes what goes on behind the scenes of this API.
> 
> Did the write() to /sys/fs/selinux/user return an error code (if so, what errno), or a string specifying that there are 0 contexts?
> 
> The underlying function first computes the maximal set of possible contexts based on the user's role authorizations and the role's type authorizations in the policy.  Then it filters that set to only include contexts for which process transition permission is allowed in policy from the caller's context (i.e. sshd in this case).
> 
> There is some further complication for the MLS field; it prefers the user's default level from the policy if that falls within the range of the caller's MLS range.  But if the user's default level is not within that range, it tries to find a level that is both consistent with the caller's MLS range limitations and the user's authorized range.  If it cannot do so, it will ultimately fail with an error.
> 
> This has long been on our todo as something to take to userspace and simplify.
> 
> 
> 

Re: What did I do wrong?

[Stephen Smalley]

On 01/21/2015 09:21 AM, Stephen Smalley wrote:
> On 01/21/2015 09:18 AM, Minear, Spencer wrote:
>> The write to /sys/fs/selinux/user was successful.  The read was successful too, but returned only "0\0".  The read return value was 2, which matches what I see coming back.  This makes me think that I am missing some information in the policy that leads to what appears to be an unexpected result rather than one or more new context's that I believe that the interface is supposed to return.
> 
> The response buffer (i.e. what you read from /sys/fs/selinux/user)
> begins with a count of the number of contexts, followed by a NUL,
> followed by the list of contexts, NUL-separated.  So in this case, the
> response is saying that it couldn't find any reachable contexts for that
> user from the calling context (whatever sshd is running in) under the
> loaded policy.  So, yes, check your user-role authorizations, your
> role-type authorizations, and transition permission from sshd's context.

Also, check the user's default level, the user's range, and what
range/level sshd is running in.

> 
>>
>> Spence
>>
>> -----Original Message-----
>> From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
>> Sent: Wednesday, January 21, 2015 7:42 AM
>> To: Minear, Spencer; SELinux (selinux@tycho.nsa.gov)
>> Subject: Re: What did I do wrong?
>>
>> On 01/20/2015 11:28 PM, Minear, Spencer wrote:
>>> Wonder if someone could give me a pointer to what my policy file is missing that would result in the /sys/fs/selinux/user API not providing a context when the sshd process context is written to that API?  I can see the behavior in a strace capture.  I believe that the action is  a call from sshd to the security_compute_user entry in libselinux.
>>>
>>> On a clean working system with the available default policy sshd writes in the sshd process's context and reads back the context that is ultimately applied to the shell process started by sshd.
>>>
>>> Obviously I'm missing something or not including some critical information into the policy but I haven't been able to find any documentation that describes what goes on behind the scenes of this API.
>>
>> Did the write() to /sys/fs/selinux/user return an error code (if so, what errno), or a string specifying that there are 0 contexts?
>>
>> The underlying function first computes the maximal set of possible contexts based on the user's role authorizations and the role's type authorizations in the policy.  Then it filters that set to only include contexts for which process transition permission is allowed in policy from the caller's context (i.e. sshd in this case).
>>
>> There is some further complication for the MLS field; it prefers the user's default level from the policy if that falls within the range of the caller's MLS range.  But if the user's default level is not within that range, it tries to find a level that is both consistent with the caller's MLS range limitations and the user's authorized range.  If it cannot do so, it will ultimately fail with an error.
>>
>> This has long been on our todo as something to take to userspace and simplify.
>>
>>
>>
> 

Re: What did I do wrong?

[Stephen Smalley]

On 01/21/2015 08:41 AM, Stephen Smalley wrote:
> On 01/20/2015 11:28 PM, Minear, Spencer wrote:
>> Wonder if someone could give me a pointer to what my policy file is missing that would result in the /sys/fs/selinux/user API not providing a context when the sshd process context is written to that API?  I can see the behavior in a strace capture.  I believe that the action is  a call from sshd to the security_compute_user entry in libselinux.
>>
>> On a clean working system with the available default policy sshd writes in the sshd process's context and reads back the context that is ultimately applied to the shell process started by sshd.
>>
>> Obviously I'm missing something or not including some critical information into the policy but I haven't been able to find any documentation that describes what goes on behind the scenes of this API.
> 
> Did the write() to /sys/fs/selinux/user return an error code (if so,
> what errno), or a string specifying that there are 0 contexts?
> 
> The underlying function first computes the maximal set of possible
> contexts based on the user's role authorizations and the role's type
> authorizations in the policy.  Then it filters that set to only include
> contexts for which process transition permission is allowed in policy
> from the caller's context (i.e. sshd in this case).
> 
> There is some further complication for the MLS field; it prefers the
> user's default level from the policy if that falls within the range of
> the caller's MLS range.  But if the user's default level is not within
> that range, it tries to find a level that is both consistent with the
> caller's MLS range limitations and the user's authorized range.  If it
> cannot do so, it will ultimately fail with an error.

Actually, looking at it again, a failure here will cause all of the
contexts to be dropped, yielding a 0-context response like the one you
are getting. So that could explain your issue.  What's the range of the
sshd process and what is the user's default level and range?

> This has long been on our todo as something to take to userspace and
> simplify.

RE: What did I do wrong?

[Minear, Spencer]

A bit more insight and by reading further into the strace I see more clues.

The interaction on /sys/fs/selinux/user, appears to work, but returns nothing.  Not sure what that may mean.

26281 open("/sys/fs/selinux/user", O_RDWR) = 4
26281 write(4, "system_u:system_r:sshd_t:s0-s0:c0.c1023 unconfined_u", 52) = 52
26281 read(4, "0\0", 4095)              = 2

A bit later I now see that the interaction on the /sys/fs/selinux/context is failing.

26281 open("/sys/fs/selinux/context", O_RDWR) = 4
26281 write(4, "unconfined_u:sysadm_r:sysadm_t:s0\0", 34) = -1 EINVAL (Invalid argument)

The subsequent error message, WHICH I have to admit I did not look for, my bad.  It provides the obvious fact:

sendto(4, "<35>Jan 21 08:35:52 sshd[26281]: error: ssh_selinux_getctxbyname: Failed to get default SELinux security context for root", 121, MSG_NOSIGNAL, NULL, 0) = 121

Now I just have to go back to the policy and figure out what I did wrong or left out of the policy construction.  Because the installation image is going to use a read only file system, the policy development has to be done on a system different than where it will run, which seems to be the more typical environment assumed by most of the information one finds.

Spence



-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
Sent: Wednesday, January 21, 2015 8:44 AM
To: Minear, Spencer; SELinux (selinux@tycho.nsa.gov)
Subject: Re: What did I do wrong?

On 01/21/2015 08:41 AM, Stephen Smalley wrote:
> On 01/20/2015 11:28 PM, Minear, Spencer wrote:
>> Wonder if someone could give me a pointer to what my policy file is missing that would result in the /sys/fs/selinux/user API not providing a context when the sshd process context is written to that API?  I can see the behavior in a strace capture.  I believe that the action is  a call from sshd to the security_compute_user entry in libselinux.
>>
>> On a clean working system with the available default policy sshd writes in the sshd process's context and reads back the context that is ultimately applied to the shell process started by sshd.
>>
>> Obviously I'm missing something or not including some critical information into the policy but I haven't been able to find any documentation that describes what goes on behind the scenes of this API.
> 
> Did the write() to /sys/fs/selinux/user return an error code (if so, 
> what errno), or a string specifying that there are 0 contexts?
> 
> The underlying function first computes the maximal set of possible 
> contexts based on the user's role authorizations and the role's type 
> authorizations in the policy.  Then it filters that set to only 
> include contexts for which process transition permission is allowed in 
> policy from the caller's context (i.e. sshd in this case).
> 
> There is some further complication for the MLS field; it prefers the 
> user's default level from the policy if that falls within the range of 
> the caller's MLS range.  But if the user's default level is not within 
> that range, it tries to find a level that is both consistent with the 
> caller's MLS range limitations and the user's authorized range.  If it 
> cannot do so, it will ultimately fail with an error.

Actually, looking at it again, a failure here will cause all of the contexts to be dropped, yielding a 0-context response like the one you are getting. So that could explain your issue.  What's the range of the sshd process and what is the user's default level and range?

> This has long been on our todo as something to take to userspace and 
> simplify.

Re: What did I do wrong?

[Stephen Smalley]

On 01/21/2015 10:08 AM, Minear, Spencer wrote:
> A bit more insight and by reading further into the strace I see more clues.
> 
> The interaction on /sys/fs/selinux/user, appears to work, but returns nothing.  Not sure what that may mean.
> 
> 26281 open("/sys/fs/selinux/user", O_RDWR) = 4
> 26281 write(4, "system_u:system_r:sshd_t:s0-s0:c0.c1023 unconfined_u", 52) = 52
> 26281 read(4, "0\0", 4095)              = 2

As I said, the response starts with a NUL-terminated count of the number
of reachable contexts found from the calling context (sshd's context) to
a valid context for the specified user (unconfined_u).  Since it
contains "0", this means that there were no reachable contexts at all
according to the policy, either due to a mismatch between the user's MLS
information (default level and range) and the range in which sshd is
running or due to a lack of transition permission from sshd's context to
any of the authorized roles and types for the unconfined_u user.

> 
> A bit later I now see that the interaction on the /sys/fs/selinux/context is failing.
> 
> 26281 open("/sys/fs/selinux/context", O_RDWR) = 4
> 26281 write(4, "unconfined_u:sysadm_r:sysadm_t:s0\0", 34) = -1 EINVAL (Invalid argument)

This is just an error path trying to fallback to a "failsafe" context
defined in /etc/selinux/targeted/contexts/failsafe_context when we
obtained no reachable contexts from the kernel.  But it is not the root
of the problem you are having; that is the lack of any reachable
contexts from sshd's context for the user.

> 
> The subsequent error message, WHICH I have to admit I did not look for, my bad.  It provides the obvious fact:
> 
> sendto(4, "<35>Jan 21 08:35:52 sshd[26281]: error: ssh_selinux_getctxbyname: Failed to get default SELinux security context for root", 121, MSG_NOSIGNAL, NULL, 0) = 121
> 
> Now I just have to go back to the policy and figure out what I did wrong or left out of the policy construction.  Because the installation image is going to use a read only file system, the policy development has to be done on a system different than where it will run, which seems to be the more typical environment assumed by most of the information one finds.
> 
> Spence
> 
> 
> 
> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
> Sent: Wednesday, January 21, 2015 8:44 AM
> To: Minear, Spencer; SELinux (selinux@tycho.nsa.gov)
> Subject: Re: What did I do wrong?
> 
> On 01/21/2015 08:41 AM, Stephen Smalley wrote:
>> On 01/20/2015 11:28 PM, Minear, Spencer wrote:
>>> Wonder if someone could give me a pointer to what my policy file is missing that would result in the /sys/fs/selinux/user API not providing a context when the sshd process context is written to that API?  I can see the behavior in a strace capture.  I believe that the action is  a call from sshd to the security_compute_user entry in libselinux.
>>>
>>> On a clean working system with the available default policy sshd writes in the sshd process's context and reads back the context that is ultimately applied to the shell process started by sshd.
>>>
>>> Obviously I'm missing something or not including some critical information into the policy but I haven't been able to find any documentation that describes what goes on behind the scenes of this API.
>>
>> Did the write() to /sys/fs/selinux/user return an error code (if so, 
>> what errno), or a string specifying that there are 0 contexts?
>>
>> The underlying function first computes the maximal set of possible 
>> contexts based on the user's role authorizations and the role's type 
>> authorizations in the policy.  Then it filters that set to only 
>> include contexts for which process transition permission is allowed in 
>> policy from the caller's context (i.e. sshd in this case).
>>
>> There is some further complication for the MLS field; it prefers the 
>> user's default level from the policy if that falls within the range of 
>> the caller's MLS range.  But if the user's default level is not within 
>> that range, it tries to find a level that is both consistent with the 
>> caller's MLS range limitations and the user's authorized range.  If it 
>> cannot do so, it will ultimately fail with an error.
> 
> Actually, looking at it again, a failure here will cause all of the contexts to be dropped, yielding a 0-context response like the one you are getting. So that could explain your issue.  What's the range of the sshd process and what is the user's default level and range?
> 
>> This has long been on our todo as something to take to userspace and 
>> simplify.
> 
> 
> 
> 

RE: What did I do wrong?

[Minear, Spencer]

Problem has been resolved.  Since I'm building/installing a monolithic policy one has to  pay more attention to which modules provide the key pieces of information that I need.  Once I came to the conclusion that the role_allow output from sesearch pointed to the missing pieces I could see I was not including the unconfined module in my policy.  This meant that the allow rules for transitions between system_r and unconfined_r was missing.   This  explains why I was seeing the 0 response from the sys/fs/selinux/user interaction.  Once this was added I get the transition as one would expect for the default policy.

Thank you for your assistance and pointers.

Spence

-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
Sent: Wednesday, January 21, 2015 9:15 AM
To: Minear, Spencer; SELinux (selinux@tycho.nsa.gov)
Subject: Re: What did I do wrong?

On 01/21/2015 10:08 AM, Minear, Spencer wrote:
> A bit more insight and by reading further into the strace I see more clues.
> 
> The interaction on /sys/fs/selinux/user, appears to work, but returns nothing.  Not sure what that may mean.
> 
> 26281 open("/sys/fs/selinux/user", O_RDWR) = 4
> 26281 write(4, "system_u:system_r:sshd_t:s0-s0:c0.c1023 unconfined_u", 52) = 52
> 26281 read(4, "0\0", 4095)              = 2

As I said, the response starts with a NUL-terminated count of the number of reachable contexts found from the calling context (sshd's context) to a valid context for the specified user (unconfined_u).  Since it contains "0", this means that there were no reachable contexts at all according to the policy, either due to a mismatch between the user's MLS information (default level and range) and the range in which sshd is running or due to a lack of transition permission from sshd's context to any of the authorized roles and types for the unconfined_u user.

> 
> A bit later I now see that the interaction on the /sys/fs/selinux/context is failing.
> 
> 26281 open("/sys/fs/selinux/context", O_RDWR) = 4
> 26281 write(4, "unconfined_u:sysadm_r:sysadm_t:s0\0", 34) = -1 EINVAL 
> (Invalid argument)

This is just an error path trying to fallback to a "failsafe" context defined in /etc/selinux/targeted/contexts/failsafe_context when we obtained no reachable contexts from the kernel.  But it is not the root of the problem you are having; that is the lack of any reachable contexts from sshd's context for the user.

> 
> The subsequent error message, WHICH I have to admit I did not look for, my bad.  It provides the obvious fact:
> 
> sendto(4, "<35>Jan 21 08:35:52 sshd[26281]: error: 
> ssh_selinux_getctxbyname: Failed to get default SELinux security 
> context for root", 121, MSG_NOSIGNAL, NULL, 0) = 121
> 
> Now I just have to go back to the policy and figure out what I did wrong or left out of the policy construction.  Because the installation image is going to use a read only file system, the policy development has to be done on a system different than where it will run, which seems to be the more typical environment assumed by most of the information one finds.
> 
> Spence
> 
> 
> 
> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
> Sent: Wednesday, January 21, 2015 8:44 AM
> To: Minear, Spencer; SELinux (selinux@tycho.nsa.gov)
> Subject: Re: What did I do wrong?
> 
> On 01/21/2015 08:41 AM, Stephen Smalley wrote:
>> On 01/20/2015 11:28 PM, Minear, Spencer wrote:
>>> Wonder if someone could give me a pointer to what my policy file is missing that would result in the /sys/fs/selinux/user API not providing a context when the sshd process context is written to that API?  I can see the behavior in a strace capture.  I believe that the action is  a call from sshd to the security_compute_user entry in libselinux.
>>>
>>> On a clean working system with the available default policy sshd writes in the sshd process's context and reads back the context that is ultimately applied to the shell process started by sshd.
>>>
>>> Obviously I'm missing something or not including some critical information into the policy but I haven't been able to find any documentation that describes what goes on behind the scenes of this API.
>>
>> Did the write() to /sys/fs/selinux/user return an error code (if so, 
>> what errno), or a string specifying that there are 0 contexts?
>>
>> The underlying function first computes the maximal set of possible 
>> contexts based on the user's role authorizations and the role's type 
>> authorizations in the policy.  Then it filters that set to only 
>> include contexts for which process transition permission is allowed 
>> in policy from the caller's context (i.e. sshd in this case).
>>
>> There is some further complication for the MLS field; it prefers the 
>> user's default level from the policy if that falls within the range 
>> of the caller's MLS range.  But if the user's default level is not 
>> within that range, it tries to find a level that is both consistent 
>> with the caller's MLS range limitations and the user's authorized 
>> range.  If it cannot do so, it will ultimately fail with an error.
> 
> Actually, looking at it again, a failure here will cause all of the contexts to be dropped, yielding a 0-context response like the one you are getting. So that could explain your issue.  What's the range of the sshd process and what is the user's default level and range?
> 
>> This has long been on our todo as something to take to userspace and 
>> simplify.
> 
> 
> 
>