Bug 120653 - login on VT as root offers system_r as optional role
login on VT as root offers system_r as optional role
Product: Fedora
Classification: Fedora
Component: policy (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2004-04-12 14:02 EDT by Gene Czarcinski
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-04-16 18:17:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Omit any reachable contexts that are not listed in default_contexts. (1.47 KB, text/plain)
2004-04-13 10:36 EDT, Stephen Smalley
no flags Details
Add entries to default_contexts to address change to libselinux (1.35 KB, text/plain)
2004-04-13 12:00 EDT, Stephen Smalley
no flags Details

  None (edit)
Description Gene Czarcinski 2004-04-12 14:02:57 EDT
Description of problem:
policy 1.10.2-5

If I login from gdm as root, I get sysadm_r as default but can also
switch to staff_r.

If I do "su -" to root, I get offered sysadm_r and staff_r as options.

If I login as root on a VT, I get offered three roles as options:
sysadm_r, staff_r, and system_r.
Comment 1 Stephen Smalley 2004-04-13 08:27:51 EDT
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

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?

Comment 2 Daniel Walsh 2004-04-13 09:08:17 EDT
How about an option to only get these, or a new function call.  
This would certainly make the presentation easier.

Comment 3 Stephen Smalley 2004-04-13 09:13:32 EDT
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, ...
Comment 4 Daniel Walsh 2004-04-13 09:27:56 EDT
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.  

Comment 5 Stephen Smalley 2004-04-13 09:30:31 EDT
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).  
Comment 6 Daniel Walsh 2004-04-13 09:41:04 EDT
Ok then lets make the change to the existing call.

Comment 7 Gene Czarcinski 2004-04-13 10:14:58 EDT
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.
Comment 8 Stephen Smalley 2004-04-13 10:36:06 EDT
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.
Comment 9 Stephen Smalley 2004-04-13 11:47:59 EDT
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.
Comment 10 Stephen Smalley 2004-04-13 11:51:09 EDT
And you need to add an entry for user_r:user_su_t.
Comment 11 Stephen Smalley 2004-04-13 12:00:18 EDT
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
includes any contexts that are not specified in default_contexts.
Comment 12 Colin Walters 2004-04-16 18:17:02 EDT
Looks like these patches have been applied, and it works for me.  Closing.

Note You need to log in before you can comment on or make changes to this bug.