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:
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.