Bug 470574 - SELinux mgetty runs unconfined_t if launched with a parameter in /etc/initttab
SELinux mgetty runs unconfined_t if launched with a parameter in /etc/initttab
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy-targeted (Show other bugs)
All Linux
high Severity high
: rc
: ---
Assigned To: Daniel Walsh
Depends On:
  Show dependency treegraph
Reported: 2008-11-07 13:54 EST by Colin.Simpson
Modified: 2012-10-16 04:42 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-20 16:30:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Colin.Simpson 2008-11-07 13:54:50 EST
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 11:00:09 EST
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 11:24:04 EST
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 13:55:39 EST
Did you manage to replicate my error?
Comment 4 Daniel Walsh 2008-11-18 14:24:02 EST
yes although I have no idea what is going on.
Comment 5 Daniel Walsh 2008-11-18 14:42:22 EST
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 14:43:43 EST
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 15:04:54 EST
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 16:30:01 EST
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.


Note You need to log in before you can comment on or make changes to this bug.