Red Hat Bugzilla – Bug 470574
SELinux mgetty runs unconfined_t if launched with a parameter in /etc/initttab
Last modified: 2012-10-16 04:42:42 EDT
Description of problem: If the mgetty program is launched from /etc/inittab with certain parameters (I think maybe in this case the -p "" parameter) it runs unconfined_t. It should run in the getty_t domain. How reproducible: Every time Steps to Reproduce: 1.If you put a line like 7:2345:respawn:/sbin/mgetty /dev/ttyS0 in /etc/inittab 2. Running, 'ps -fZ -C mgetty' produces: system_u:system_r:getty_t:s0 root 5485 1 0 18:40 ? 00:00:00 /sbin/mgetty /dev/ttyS0 which is correctly running in getty_t. 3.However if I put the following line in /etc/inittab : 7:2345:respawn:/sbin/mgetty -p "" -i /etc/issue -D /dev/ttyS0 4. Running, 'ps -fZ -C mgetty' produces: system_u:system_r:unconfined_t:s0 root 5542 1 0 18:47 ? 00:00:00 /sbin/mgetty -p -i /etc/issue -D /dev/ttyS0 It's now running unconfined_t! It should still run in getty_t. Additional info: I think it maybe the -p option with quoted parameters that makes the difference for some reason. A workaround is to put a login-prompt line into mgetty.config and leave it out of inittab.
Are you sure about this? This looks like you ran mgetty directly? If you reboot does it cume up running as unconfined_t?
It was run from inittab not directly (I presume you mean by that, run from a shell?). Then a HUP sent to init (and usually killing the existing mgetty). Just tried a reboot, and it comes up unconfined_t! It definitely seems related to having the quotes in that line (on the -p flag). The bottom of my inittab reads. It comes up unconfined_t for all but the line without the -p parameter (2nd last). # Run mgetty for the modem #7:2345:respawn:/sbin/mgetty -p "" -i /etc/issue.ppp ttyS0 -D /dev/ttyS0 #7:2345:respawn:/sbin/mgetty /dev/ttyS0 7:2345:respawn:/sbin/mgetty -p "" /dev/ttyS0 # ps -fZ -C mgetty LABEL UID PID PPID C STIME TTY TIME CMD system_u:system_r:unconfined_t root 4719 1 0 16:15 ? 00:00:00 /sbin/mgetty -p /dev/ttyS I thought it was pretty strange that's why I raised it in case it was a parsing error that could cause security issues elsewhere in SELinux.
Did you manage to replicate my error?
yes although I have no idea what is going on.
I think what is happening is init is execing a shell when you use the /sbin/mgetty -P "" As opposed to execing /sbin/mgetty directly otherwise.
SELinux policy in RHEL5 says that if init_t execs a program labeled shell_exec_t it will execute it as unconfined_t, It also says that if init_t executes getty_exec_t it will run it as getty_t.
Ok the problem is that init searches for a bunch of special characters on the command line include \" and executes a shell if it finds one, otherwise init executes the command line directly. SELinux policy was setup for running single user mode in uncofined_t which involves init executing a shell directly. In strict/mls policy it executes sysadm_t. I can take away the transition from init_t -> shell_exec_t -> unconfined_t which will fix the problem for running getty, but will end up with single user mode running as init_t. init_t in targeted policy is an unconfined domain, so this should not be a problem. There are potential problems if a transition happens. It looks like if you are logged in as init_t and execute getty_exec_t, initrc_exec_t, xdm_exec_t, sulogin_exec_t you will transition to the corresponding domain. Fixed in selinux-policy-2.4.6-190.el5
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-0163.html