Bug 145876

Can you try 
make -C /etc/selinux/strict/src/policy load 

and see if this goes away?

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.

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.

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.

This looks to be very hacky.  I am not crazy about doing this.  

Bill, do you have any ideas?

Dan

Can we do the auto transation only when it's execed by init?

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.

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. 

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

What is the status of this bug?
I think it's still broken. 
Will init be changed?

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

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

Adding as a blocker against the SELinux FAQ tracker bug #118757.

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.