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@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
