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
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy-targeted (Show other bugs)
5.2
All Linux
high Severity high
: rc
: ---
Assigned To: Daniel Walsh
BaseOS QE
:
Depends On:
Blocks:
  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:
Environment:
Last Closed: 2009-01-20 16:30:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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.

http://rhn.redhat.com/errata/RHBA-2009-0163.html

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