sshd and default security context.

sshd and default security context.

[dE]

I was tying out default_contexts which has the following lines  --

cat default_contexts | grep sshd
system_r:sshd_t:s0              user_r:user_t:s0

And sshd does run with that type --

ps auxZ | grep sshd
system_u:system_r:sshd_t:s0-s0:c0.c1023 root 279 0.0  0.6 80636 3392 
?        Ss   09:20   0:00 /usr/sbin/sshd -D
system_u:system_r:sshd_t:s0-s0:c0.c1023 root 458 0.0  0.9 131280 4652 
?        Ss   09:22   0:00 sshd: de [priv]
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 de 468 0.0 0.4 
131280 2144 ? S 09:22   0:00 sshd: de@pts/0
system_u:system_r:sshd_t:s0-s0:c0.c1023 root 5115 1.1  0.9 131280 4624 
?       Ss   20:22   0:00 sshd: de [priv]
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 de 5121 0.0 0.4 
131280 2124 ? S 20:22   0:00 sshd: de@notty

But the processes spawned by sshd do not have type user_t --

ps auxZ | grep user_t
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 de 5183 0.0 0.1 
112632 884 pts/0 S+ 20:25   0:00 grep --color=auto user_t

I'm running the sleep command over SSH for e.g. but --

ps auxZ | grep sleep
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 de 5126 0.0 0.1 
107888 504 ? Ss 20:22   0:00 sleep 10m

ps f -Ao args,label

COMMAND                     LABEL
/usr/sbin/sshd -D           system_u:system_r:sshd_t:s0-s0:c0.c1023
  \_ sshd: de [priv]         system_u:system_r:sshd_t:s0-s0:c0.c1023
  |   \_ sshd: de@pts/0 
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
  |       \_ -bash unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
  |           \_ ps f -Ao ar 
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
  \_ sshd: de [priv]         system_u:system_r:sshd_t:s0-s0:c0.c1023
      \_ sshd: de@notty 
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
          \_ sleep 10m unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

I'm aware of the possibility that ssh devs may have intended to use 
libselinux for a different purpose, but it's kind of pointless otherwise.

ldd $(which sshd) | grep selinux
         libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f4cf93f6000)

Re: sshd and default security context.

[Stephen Smalley]

On 05/07/2014 11:32 AM, dE wrote:
> I was tying out default_contexts which has the following lines  --
> 
> cat default_contexts | grep sshd
> system_r:sshd_t:s0              user_r:user_t:s0
> 
> And sshd does run with that type --
> 
> ps auxZ | grep sshd
> system_u:system_r:sshd_t:s0-s0:c0.c1023 root 279 0.0  0.6 80636 3392
> ?        Ss   09:20   0:00 /usr/sbin/sshd -D
> system_u:system_r:sshd_t:s0-s0:c0.c1023 root 458 0.0  0.9 131280 4652
> ?        Ss   09:22   0:00 sshd: de [priv]
> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 de 468 0.0 0.4
> 131280 2144 ? S 09:22   0:00 sshd: de@pts/0
> system_u:system_r:sshd_t:s0-s0:c0.c1023 root 5115 1.1  0.9 131280 4624
> ?       Ss   20:22   0:00 sshd: de [priv]
> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 de 5121 0.0 0.4
> 131280 2124 ? S 20:22   0:00 sshd: de@notty
> 
> But the processes spawned by sshd do not have type user_t --
> 
> ps auxZ | grep user_t
> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 de 5183 0.0 0.1
> 112632 884 pts/0 S+ 20:25   0:00 grep --color=auto user_t

The Linux user is mapped to a SELinux user based on the seusers mapping;
you can run semanage login -l to see the mapping.  The __default__ entry
is used when there is no other match, so under targeted policy, users
default to being mapped to unconfined_u.  If you want them to run in a
confined role, you can use semanage login -a to map their Linux username
to a confined SELinux user like user_u or staff_u.

libselinux asks the kernel for the set of security contexts for the
SELinux user reachable from the current context, which in this case is
system_u:system_r:sshd_t.  This is done via security_compute_user()
which internally writes a query to /sys/fs/selinux/user and reads back a
list of contexts.  The kernel computes this list from policy based on
the user-role relation, the user-level relation, the role-type relation,
and whether or not process transition permission is granted from the
current context (i.e. sshd's context) to the context in policy.

Then, libselinux looks to see if there is an
/etc/selinux/$SELINUXTYPE/contexts/users/<selinux-user> file, e.g.
/etc/selinux/targeted/contexts/unconfined_u, and if so, uses it to
determine the most preferred context(s) to use.

Then, libselinux looks to see if there is an
/etc/selinux/$SELINUXTYPE/contexts/default_contexts file, and if so,
uses it to determine the next most preferred context(s) to use.

libselinux orders the list of contexts based on these two configuration
files and then returns the result to the caller for selection.  Most
current callers just use the most preferred context, but the design was
to allow user selection via some interfaces, e.g. some people have
implemented gdm extensions or the like that offered the user a choice of
contexts at login time.

If something goes wrong and it cannot obtain any valid contexts in this
way, libselinux falls back to trying to use a context based on
/etc/selinux/$SELINUXTYPE/contexts/failsafe_context.  This was to permit
e.g. root login for emergency recovery.  If the user in question isn't
authorized for that context however, this will fail, so it can only work
if the user is authorized for that role.

The mechanism is overly complex and can be fragile, which has led to
some changes over time to try to reduce fragility at a cost in the
original expressiveness/generality of the mechanism.  I'd prefer to
rework it to avoid the kernel interaction altogether, but this would
require some exporting some of the kernel policy information to
userspace (either via other /sys/fs/selinux nodes or by extracting the
information during policy build and placing it in configuration files
made available to userspace) and reworking the userspace logic.

There is a fair bit of complexity as well in the pam_selinux logic even
before you reach libselinux that would benefit from streamlining and
possibly taking to libselinux.

Re: sshd and default security context.

[dE]

On 05/08/14 00:14, Stephen Smalley wrote:
> On 05/07/2014 11:32 AM, dE wrote:
>> I was tying out default_contexts which has the following lines  --
>>
>> cat default_contexts | grep sshd
>> system_r:sshd_t:s0              user_r:user_t:s0
>>
>> And sshd does run with that type --
>>
>> ps auxZ | grep sshd
>> system_u:system_r:sshd_t:s0-s0:c0.c1023 root 279 0.0  0.6 80636 3392
>> ?        Ss   09:20   0:00 /usr/sbin/sshd -D
>> system_u:system_r:sshd_t:s0-s0:c0.c1023 root 458 0.0  0.9 131280 4652
>> ?        Ss   09:22   0:00 sshd: de [priv]
>> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 de 468 0.0 0.4
>> 131280 2144 ? S 09:22   0:00 sshd: de@pts/0
>> system_u:system_r:sshd_t:s0-s0:c0.c1023 root 5115 1.1  0.9 131280 4624
>> ?       Ss   20:22   0:00 sshd: de [priv]
>> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 de 5121 0.0 0.4
>> 131280 2124 ? S 20:22   0:00 sshd: de@notty
>>
>> But the processes spawned by sshd do not have type user_t --
>>
>> ps auxZ | grep user_t
>> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 de 5183 0.0 0.1
>> 112632 884 pts/0 S+ 20:25   0:00 grep --color=auto user_t
> The Linux user is mapped to a SELinux user based on the seusers mapping;
> you can run semanage login -l to see the mapping.  The __default__ entry
> is used when there is no other match, so under targeted policy, users
> default to being mapped to unconfined_u.  If you want them to run in a
> confined role, you can use semanage login -a to map their Linux username
> to a confined SELinux user like user_u or staff_u.
>
> libselinux asks the kernel for the set of security contexts for the
> SELinux user reachable from the current context, which in this case is
> system_u:system_r:sshd_t.  This is done via security_compute_user()
> which internally writes a query to /sys/fs/selinux/user and reads back a
> list of contexts.  The kernel computes this list from policy based on
> the user-role relation, the user-level relation, the role-type relation,
> and whether or not process transition permission is granted from the
> current context (i.e. sshd's context) to the context in policy.
>
> Then, libselinux looks to see if there is an
> /etc/selinux/$SELINUXTYPE/contexts/users/<selinux-user> file, e.g.
> /etc/selinux/targeted/contexts/unconfined_u, and if so, uses it to
> determine the most preferred context(s) to use.
>
> Then, libselinux looks to see if there is an
> /etc/selinux/$SELINUXTYPE/contexts/default_contexts file, and if so,
> uses it to determine the next most preferred context(s) to use.
>
> libselinux orders the list of contexts based on these two configuration
> files and then returns the result to the caller for selection.  Most
> current callers just use the most preferred context, but the design was
> to allow user selection via some interfaces, e.g. some people have
> implemented gdm extensions or the like that offered the user a choice of
> contexts at login time.
>
> If something goes wrong and it cannot obtain any valid contexts in this
> way, libselinux falls back to trying to use a context based on
> /etc/selinux/$SELINUXTYPE/contexts/failsafe_context.  This was to permit
> e.g. root login for emergency recovery.  If the user in question isn't
> authorized for that context however, this will fail, so it can only work
> if the user is authorized for that role.
>
> The mechanism is overly complex and can be fragile, which has led to
> some changes over time to try to reduce fragility at a cost in the
> original expressiveness/generality of the mechanism.  I'd prefer to
> rework it to avoid the kernel interaction altogether, but this would
> require some exporting some of the kernel policy information to
> userspace (either via other /sys/fs/selinux nodes or by extracting the
> information during policy build and placing it in configuration files
> made available to userspace) and reworking the userspace logic.
>
> There is a fair bit of complexity as well in the pam_selinux logic even
> before you reach libselinux that would benefit from streamlining and
> possibly taking to libselinux.

Thanks for clarifying. I forgot the check the user based security 
context, so it changed it to --

cat /etc/selinux/targeted/contexts/users/unconfined_u | grep sshd
system_r:sshd_t:s0              user_r:user_t:s0

 From unconfined_r:unconfined_t:s0

But apparently the policies don't allow that. I'm running as user 
unconfined_u.

Re: sshd and default security context.

[Stephen Smalley]

On 05/09/2014 01:59 AM, dE wrote:
> On 05/08/14 00:14, Stephen Smalley wrote:
>> On 05/07/2014 11:32 AM, dE wrote:
>>> I was tying out default_contexts which has the following lines  --
>>>
>>> cat default_contexts | grep sshd
>>> system_r:sshd_t:s0              user_r:user_t:s0
>>>
>>> And sshd does run with that type --
>>>
>>> ps auxZ | grep sshd
>>> system_u:system_r:sshd_t:s0-s0:c0.c1023 root 279 0.0  0.6 80636 3392
>>> ?        Ss   09:20   0:00 /usr/sbin/sshd -D
>>> system_u:system_r:sshd_t:s0-s0:c0.c1023 root 458 0.0  0.9 131280 4652
>>> ?        Ss   09:22   0:00 sshd: de [priv]
>>> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 de 468 0.0 0.4
>>> 131280 2144 ? S 09:22   0:00 sshd: de@pts/0
>>> system_u:system_r:sshd_t:s0-s0:c0.c1023 root 5115 1.1  0.9 131280 4624
>>> ?       Ss   20:22   0:00 sshd: de [priv]
>>> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 de 5121 0.0 0.4
>>> 131280 2124 ? S 20:22   0:00 sshd: de@notty
>>>
>>> But the processes spawned by sshd do not have type user_t --
>>>
>>> ps auxZ | grep user_t
>>> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 de 5183 0.0 0.1
>>> 112632 884 pts/0 S+ 20:25   0:00 grep --color=auto user_t
>> The Linux user is mapped to a SELinux user based on the seusers mapping;
>> you can run semanage login -l to see the mapping.  The __default__ entry
>> is used when there is no other match, so under targeted policy, users
>> default to being mapped to unconfined_u.  If you want them to run in a
>> confined role, you can use semanage login -a to map their Linux username
>> to a confined SELinux user like user_u or staff_u.
>>
>> libselinux asks the kernel for the set of security contexts for the
>> SELinux user reachable from the current context, which in this case is
>> system_u:system_r:sshd_t.  This is done via security_compute_user()
>> which internally writes a query to /sys/fs/selinux/user and reads back a
>> list of contexts.  The kernel computes this list from policy based on
>> the user-role relation, the user-level relation, the role-type relation,
>> and whether or not process transition permission is granted from the
>> current context (i.e. sshd's context) to the context in policy.
>>
>> Then, libselinux looks to see if there is an
>> /etc/selinux/$SELINUXTYPE/contexts/users/<selinux-user> file, e.g.
>> /etc/selinux/targeted/contexts/unconfined_u, and if so, uses it to
>> determine the most preferred context(s) to use.
>>
>> Then, libselinux looks to see if there is an
>> /etc/selinux/$SELINUXTYPE/contexts/default_contexts file, and if so,
>> uses it to determine the next most preferred context(s) to use.
>>
>> libselinux orders the list of contexts based on these two configuration
>> files and then returns the result to the caller for selection.  Most
>> current callers just use the most preferred context, but the design was
>> to allow user selection via some interfaces, e.g. some people have
>> implemented gdm extensions or the like that offered the user a choice of
>> contexts at login time.
>>
>> If something goes wrong and it cannot obtain any valid contexts in this
>> way, libselinux falls back to trying to use a context based on
>> /etc/selinux/$SELINUXTYPE/contexts/failsafe_context.  This was to permit
>> e.g. root login for emergency recovery.  If the user in question isn't
>> authorized for that context however, this will fail, so it can only work
>> if the user is authorized for that role.
>>
>> The mechanism is overly complex and can be fragile, which has led to
>> some changes over time to try to reduce fragility at a cost in the
>> original expressiveness/generality of the mechanism.  I'd prefer to
>> rework it to avoid the kernel interaction altogether, but this would
>> require some exporting some of the kernel policy information to
>> userspace (either via other /sys/fs/selinux nodes or by extracting the
>> information during policy build and placing it in configuration files
>> made available to userspace) and reworking the userspace logic.
>>
>> There is a fair bit of complexity as well in the pam_selinux logic even
>> before you reach libselinux that would benefit from streamlining and
>> possibly taking to libselinux.
> 
> Thanks for clarifying. I forgot the check the user based security
> context, so it changed it to --
> 
> cat /etc/selinux/targeted/contexts/users/unconfined_u | grep sshd
> system_r:sshd_t:s0              user_r:user_t:s0
> 
> From unconfined_r:unconfined_t:s0
> 
> But apparently the policies don't allow that. I'm running as user
> unconfined_u.

That's correct; semanage user -l will show you that unconfined_u is only
authorized for system_r and unconfined_r, not for user_r.  To login as
user_r, you need to assign user_u to your Linux username via semanage
login -a.