Bug 470574

Summary: SELinux mgetty runs unconfined_t if launched with a parameter in /etc/initttab
Product: Red Hat Enterprise Linux 5 Reporter: Colin.Simpson
Component: selinux-policy-targetedAssignee: Daniel Walsh <dwalsh>
Status: CLOSED ERRATA QA Contact: BaseOS QE <qe-baseos-auto>
Severity: high Docs Contact:
Priority: high    
Version: 5.2CC: dwalsh, kwirth, mmalik, nalin, notting, syeghiay
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-20 21:30:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Colin.Simpson 2008-11-07 18:54:50 UTC
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.

Comment 1 Daniel Walsh 2008-11-10 16:00:09 UTC
Are you sure about this?  This looks like you ran mgetty directly?  If you reboot does it cume up running as unconfined_t?

Comment 2 Colin.Simpson 2008-11-10 16:24:04 UTC
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.

Comment 3 Colin.Simpson 2008-11-18 18:55:39 UTC
Did you manage to replicate my error?

Comment 4 Daniel Walsh 2008-11-18 19:24:02 UTC
yes although I have no idea what is going on.

Comment 5 Daniel Walsh 2008-11-18 19:42:22 UTC
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.

Comment 6 Daniel Walsh 2008-11-18 19:43:43 UTC
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.

Comment 7 Daniel Walsh 2008-11-18 20:04:54 UTC
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

Comment 13 errata-xmlrpc 2009-01-20 21:30:01 UTC
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