Bug 120653

The present scheme asks the kernel for the set of reachable contexts
from the current context for the particular user, and then orders the
resulting contexts based on /etc/security/default_contexts and
$HOME/.default_contexts.

In the case of login and system_r, the cause is that:
a) admins are presently authorized for system_r to support direct
daemon restarts without using run_init.
b) login runs in system_r, so there is no role change required to stay
in system_r.
c) system_r is authorized for sysadm_t to support single-user mode boots.
d) login can set the user identity and can transition to sysadm_t.

Hence, system_u:system_r:local_login_t -> root:system_r:sysadm_t is
authorized by the policy.

Running su from root:staff_r:staff_t also shows some "bad" contexts,
e.g. root:staff_r:staff_chkpwd_t and root:staff_r:staff_xauth_t,
because these do not require a user identity or role change (so the
constraints don't figure into the equation) and su is authorized to
run the chkpwd and xauth helpers in their appropriate domains, so
these contexts can be reached by su under the current policy (but
selecting them from the option list will fail since they cannot be
entered via the shell).

Perhaps we need to change the get_ordered_context_list logic in
libselinux so that it does not return any contexts obtained from the
kernel that are not listed in /etc/security/default_contexts or
$HOME/.default_contexts.  Thoughts?

How about an option to only get these, or a new function call.  
This would certainly make the presentation easier.

Dan

I can add a new function call with these semantics if you prefer, but
that would then require updating all callers of the old function and
rebuilding all of those packages.  Is there a reason why we would want
to retain the old semantics?  If not, I'd suggest just changing the
internal implementation of the existing function, thereby avoiding any
need to modify or rebuild pam_selinux, gdm, crond, ...
 

That is fine, but we might envision a scenario where you would want to
get all possible contexts that a role could transition too. 

So maybe a new function to give the previous functionality?

Just for debugging purposes it might be usefull.  

Dan

You would still be able to call the kernel interface directly
(security_compute_user) to get the full set of reachable contexts for
the user.  get_ordered_context_list calls that interface and then orders
the contexts based on the default_contexts.  So we'll just be changing
get_ordered_context_list to omit anything not in default_contexts (but
still vet each entry in default_contexts against the kernel list, to
prevent unauthorized contexts).  

Ok then lets make the change to the existing call.

Dan

I am going to subit an RFE on this since I do not see how else to get
the info and this might address Dan's comment #4 -- RFE to provide a
command which will list all available roles for that user.

Created attachment 99361 [details]
Omit any reachable contexts that are not listed in default_contexts.

This patch for libselinux will cause get_ordered_context_list to omit any
reachable contexts that are not explicitly listed in default_contexts.

Note that you should also review and amend default_contexts to ensure
that you have all desired contexts listed, e.g. the staff_su_t and
sysadm_su_t entries likely should have user_r:user_t added to the end
of the list for su'ing to a non-admin account.

And you need to add an entry for user_r:user_su_t.

Created attachment 99362 [details]
Add entries to default_contexts to address change to libselinux

This patch for default_contexts adds contexts to the entries for sshd, crond,
and su to address the fact that the new get_ordered_context_list logic no
longer
includes any contexts that are not specified in default_contexts.

Looks like these patches have been applied, and it works for me.  Closing.