Bug 145876 - Unable to su in single mode
Unable to su in single mode
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy-strict (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks: 118757 fc-relnotes-traqr
  Show dependency treegraph
 
Reported: 2005-01-22 18:11 EST by Ivan Gyurdiev
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version: 1.25.4-10.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-15 11:59:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ivan Gyurdiev 2005-01-22 18:11:22 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041228 Firefox/1.0 Fedora/1.0-8

Description of problem:
audit(1106432753.125:0): security_compute_sid:  invalid context
system_u:system_r:sysadm_chkpwd_t for
scontext=system_u:system_r:sysadm_su_t
tcontext=system_u:object_r:chkpwd_exec_t tclass=process




Version-Release number of selected component (if applicable):
selinux-policy-strict-1.21.2-7

How reproducible:
Didn't try

Steps to Reproduce:
  

Additional info:
Comment 1 Daniel Walsh 2005-01-24 15:53:46 EST
Can you try 
make -C /etc/selinux/strict/src/policy load 

and see if this goes away?
Comment 2 Ivan Gyurdiev 2005-01-24 21:40:29 EST
Reload the policy? I always do that. It doesn't fix it.
Why is the single user role system_r. Shouldn't it be sysadm_r? 

system_r's not allowed to sysadm_chkpwd_t I think

Where is the role set - I couldn't figure that out.
Comment 3 Stephen Smalley 2005-01-25 10:05:16 EST
sulogin will manually set the security context for you if you have configured
/etc/inittab to run it for single-user mode, see man 5 inittab.
Otherwise, there is a default transition to sysadm_t when init runs a shell, but
that won't set the role.  And we likely don't want to auto transition roles from
system_r to sysadm_r upon shell_exec_t, as that would have other implications.
Comment 4 Stephen Smalley 2005-01-25 11:07:00 EST
Need to patch init to explicitly set the security context if the single user shell
is not sulogin.  Just a get_default_context("root", NULL, &newcon);
setexeccon(newcon); prior to exec'ing the single user shell.
Comment 5 Daniel Walsh 2005-01-26 18:12:07 EST
This looks to be very hacky.  I am not crazy about doing this.  

Bill, do you have any ideas?

Dan
Comment 6 Bill Nottingham 2005-01-27 00:36:46 EST
Can we do the auto transation only when it's execed by init?
Comment 7 Stephen Smalley 2005-01-27 07:14:30 EST
No, role transitions are just based on the current role and the program file's
TE type, e.g. role_transition system_r shell_exec_t sysadm_r;, and that would
affect all system processes.  Now, it should be noted that this is only an issue
with strict policy, not targeted, and that if someone is using strict policy, we
could just recommend that they change inittab to run sulogin as the single user
shell, as that is what any security-conscious person is going to do anyway.  Not
sure why it isn't the default.
Comment 8 Bill Nottingham 2005-01-27 12:26:06 EST
The reason it's not the default is because if you can get to single user mode,
you can already get root, easily. (either through other bootloader args, or, if
you're running 'telinit', you're already root. So, an additional request of the
root password is not generally useful without other changes. 
Comment 9 Ivan Gyurdiev 2005-02-09 20:30:33 EST
Status of this bug from a user's perspective:

- still in system_r
- su to root opens and closes session immediately with no denials in enforcing mode
- su to root works fine in permissive mode with the following denials:

audit(1107996617.937:0): avc:  denied  { relabelfrom } for  pid=2158 exe=/bin/su
name=console dev=tmpfs ino=531 scontext=system_u:system_r:sysadm_su_t
tcontext=system_u:object_r:console_device_t tclass=chr_file

audit(1107996617.937:0): avc:  denied  { relabelto } for  pid=2158 exe=/bin/su
name=console dev=tmpfs ino=531 scontext=system_u:system_r:sysadm_su_t
tcontext=root:object_r:console_device_t tclass=chr_file

- su to regular user produces the following denial:

audit(1107996433.925:0): avc:  denied  { read write } for  pid=2078
exe=/bin/bash name=console dev=tmpfs ino=531 scontext=user_u:user_r:user_t
tcontext=system_u:object_r:console_device_t tclass=chr_file

Comment 10 Ivan Gyurdiev 2005-03-13 00:45:23 EST
What is the status of this bug?
I think it's still broken. 
Will init be changed?
Comment 11 Daniel Walsh 2005-04-21 09:24:43 EDT
I think I agree with Steven the best solution is to recommend

Change inittab to run sulogin as the single user shell.

              ~:S:wait:/sbin/sulogin

Be added to inittab for strict/mls policy.

Dan
Comment 12 Ivan Gyurdiev 2005-05-10 12:26:52 EDT
I thought this was supposed to be fixed?
I remember seeing something in the Fedora changelog about 
using sulogin. Retested and it's still broken.

I see an inittab.rpmnew in /etc, but the only thing it 
changes is to set my default runlevel to 3 (not sure why).

This is: initscripts-8.09-1



Comment 13 Karsten Wade 2005-09-15 14:50:39 EDT
Adding as a blocker against the SELinux FAQ tracker bug #118757.
Comment 14 Karsten Wade 2005-09-15 14:53:09 EDT
Oops, also added the master release notes tracker bug #151189 as a blocker. 
We'll track this recommendation for inclusion in the FC5 test/release notes, if
needed.

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