Reachable SIDs given a context

Reachable SIDs given a context

[Sven Vermeulen]

tl;dr How does the policy dictate what the valid SIDs are that can be
      reached given a certain context (like system_r:crond_t)? And how
      can a policy writer/developer work on this?

I'm trying to understand how to work with the contexts/default_contexts and
contexts/users/* files. As I understood it, the file give the default
contexts to use if a logon-like process (or any process that sets up a PAM
session for a user where PAM triggers pam_selinux.so) is used.

However, it seems like just modifying the files isn't sufficient. I try
reproducing stuff using getseuser command. For instance:

# getseuser root system_u:system_r:crond_t
seuser:  root, level (null)
Context 0       root:sysadm_r:cronjob_t
Context 1       root:staff_r:cronjob_t

This still matches what is in the default_contexts file for the crond_t
domain (and in the specific user file in contexts/users/root):

system_r:crond_t        unconfined_r:unconfined_t sysadm_r:cronjob_t
			staff_r:cronjob_t user_r:cronjob_t

As the root Linux user maps on the root SELinux user, which has staff_r and
sysadm_r as allowed roles, and because of the order in the file, I get the
sysadm_r:cronjob_t first and then staff_r:cronjob_t.

However, when I try to modify the contexts/root file so that another domain
should be used (say portage_t), getseuser still returns the standard
cronjob_t domains:

~# grep crond_t users/root
system_r:crond_t        unconfined_r:unconfined_t sysadm_r:portage_t
			staff_r:portage_t user_r:cronjob_t

~# getseuser root system_u:system_r:crond_t
seuser:  root, level (null)
Context 0       root:staff_r:cronjob_t
Context 1       root:sysadm_r:cronjob_

If I strace getseuser, I notice it first asks the SELinux in-kernel code on
what the contexts are that crond_t can return to for the user (the SIDs),
and then it reads the users/root and default_contexts files. 

The kernel (through /sys/fs/selinux/user) returns 
3715  read(3, "2\0root:staff_r:cronjob_t\0root:sysadm_r:cronjob_t\0", 4095) = 49

In the kernel code I "read" (interpret might be better ;) that the policy is
checked to see what valid SIDs can be reached from the given context (the
system_r:crond_t context) which are then translated into contexts and
returned. I assume that getseuser then sees if one of the files (users/root
and default_contexts) sais the same. When one match occurs, then that is
returned. If none occur, then the value returned by the kernel is used.

How does the kernel know what the valid, reachable SIDs are? I first thought
it was the domains that can be transitioned to, but crond_t can transition
to portage_t, and portage_t is allowed for the sysadm_r role.

Wkr,
	Sven Vermeulen

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Reachable SIDs given a context

[Stephen Smalley]

On 12/13/2012 04:15 AM, Sven Vermeulen wrote:
> tl;dr How does the policy dictate what the valid SIDs are that can be
>        reached given a certain context (like system_r:crond_t)? And how
>        can a policy writer/developer work on this?
>
> I'm trying to understand how to work with the contexts/default_contexts and
> contexts/users/* files. As I understood it, the file give the default
> contexts to use if a logon-like process (or any process that sets up a PAM
> session for a user where PAM triggers pam_selinux.so) is used.
>
> However, it seems like just modifying the files isn't sufficient. I try
> reproducing stuff using getseuser command. For instance:
>
> # getseuser root system_u:system_r:crond_t
> seuser:  root, level (null)
> Context 0       root:sysadm_r:cronjob_t
> Context 1       root:staff_r:cronjob_t
>
> This still matches what is in the default_contexts file for the crond_t
> domain (and in the specific user file in contexts/users/root):
>
> system_r:crond_t        unconfined_r:unconfined_t sysadm_r:cronjob_t
> 			staff_r:cronjob_t user_r:cronjob_t
>
> As the root Linux user maps on the root SELinux user, which has staff_r and
> sysadm_r as allowed roles, and because of the order in the file, I get the
> sysadm_r:cronjob_t first and then staff_r:cronjob_t.
>
> However, when I try to modify the contexts/root file so that another domain
> should be used (say portage_t), getseuser still returns the standard
> cronjob_t domains:
>
> ~# grep crond_t users/root
> system_r:crond_t        unconfined_r:unconfined_t sysadm_r:portage_t
> 			staff_r:portage_t user_r:cronjob_t
>
> ~# getseuser root system_u:system_r:crond_t
> seuser:  root, level (null)
> Context 0       root:staff_r:cronjob_t
> Context 1       root:sysadm_r:cronjob_
>
> If I strace getseuser, I notice it first asks the SELinux in-kernel code on
> what the contexts are that crond_t can return to for the user (the SIDs),
> and then it reads the users/root and default_contexts files.
>
> The kernel (through /sys/fs/selinux/user) returns
> 3715  read(3, "2\0root:staff_r:cronjob_t\0root:sysadm_r:cronjob_t\0", 4095) = 49
>
> In the kernel code I "read" (interpret might be better ;) that the policy is
> checked to see what valid SIDs can be reached from the given context (the
> system_r:crond_t context) which are then translated into contexts and
> returned. I assume that getseuser then sees if one of the files (users/root
> and default_contexts) sais the same. When one match occurs, then that is
> returned. If none occur, then the value returned by the kernel is used.
>
> How does the kernel know what the valid, reachable SIDs are? I first thought
> it was the domains that can be transitioned to, but crond_t can transition
> to portage_t, and portage_t is allowed for the sysadm_r role.

Yes, I think the only thing you are missing is that the kernel also 
applies any constraint checking when it checks the transition 
permission, and we have this in policy/constraints:
         or ( t1 == cron_source_domain and ( t2 == cron_job_domain or u2 
== system_u ) )

So you need domain_cron_exemption_target(portage_t) in your policy.

BTW, we'd like to get rid of the usage of /selinux/user altogether; that 
has been previously discussed on list.  Preferably simplifying the logic 
and moving it to userspace.










--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.