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. _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
