Red Hat Bugzilla – Bug 218922
RIT107328 - LSPP - Run_init fails to run if spawned by Expect as sysadm
Last modified: 2007-11-30 17:07:38 EST
Run_init does not run properly if executed as sysadm_r:sysadm_t from within an
Expect script. Error happens in Enforcing mode only.
Same test run as auditadm_r:auditadm_t in Enforcing mode works as expected.
Contact Information = Eduardo Fleury <firstname.lastname@example.org>
Linux zaphod.ltc.br.ibm.com 2.6.18-1.2740.el5 #1 SMP Wed Nov 1 20:42:07 EST 2006
ppc64 ppc64 ppc64 GNU/Linux
Linux norris.ltc.ic.unicamp.br 2.6.18-1.2747.2.1.el5.lspp.55 #1 SMP Fri Nov 10
12:22:22 EST 2006 i686 i686 i386 GNU/Linux
Tested with the stock kernel as well as LSPP kernels 54 and 55. Same result was
seen in all tests.
RHEL5 Beta2 11/11/06 system installed with LSPP Kick Start script v0.10-1.
Also tested with v0.9-1 and Beta1 refresh 11/02.
Machine Type = pSeries
A debugger is not configured
---Steps to Reproduce---
1) Login as an admin user
2) Disable enforcing mode
3) Newrole to sysadm_r:sysadm_t
4) run attached script (expri) passing the user password as the first argument like:
The run_init usage string will be shown, this was the expected result.
5) Turn enforcing mode on (setenforce 1)
Repeat the 4th step. The usage string will not appear, it was expected it did
6) Still in enforcing mode, newrole to auditadm_r:auditadm_t
7) Repeat the 4th step again. The usage string will be shown even though we are
in enforcing mode.
This proves the bug appears only in enforcing mode and only as sysadm_r:sysadm_t.
Calling run_init directly (ie, w/o Expect) works fine as sysadm_r:sysadm_t in
---Security Component Data---
Userspace tool common name: run_init and expect
"rpm -qa | grep -i selinux" output:
The userspace tool has the following bit modes: both 32 & 64
Userspace rpm: policycoreutils-1.32-1 and expect-5.43.0-5.1
See attached file for log messages.
Created attachment 143150 [details]
Audit log messages for success and fail cases.
Created attachment 143151 [details]
Test script used to reproduce this bug.
This script tries to execute "run_init service" and send the user password when
asked to do so.
Usage: ./expri <user_password>
Requires "Expect" to be installed (it's installed by default in the LSPP
Potential work around, does adding
pam_rootok to /etc/pam.d/run_init fix this problem?
Hi Daniel, I'm sorry I'm not used to pam configuration. How you suggest I
include that in order to perform the test?
I've tried adding it as:
"auth sufficient pam_rootok.so" but that makes it skip the password check at
all, which is not what we want.
Adding as "include" instead of "sufficent" will make run_init stop from working
even if manually called.
Sorry, I thought you wanted to test service startups. But if you want to test
that run_init asks the questions, you do not want to add pam_rootok.
I am not sure we want to add policy to make your test work. In order to make it
work, we would need to allow init scripts access to open fd's and fifo_pipes
created by the sysadm_t.
You could create your own policy module to go along with this test, via
audit2allow -M mytest < /var/log/audit/audit.log.
This is what our qa team is doing when the test actually causes SELinux problems.