Bug 197574 - selinux breaks vgetty
selinux breaks vgetty
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
5
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-04 05:38 EDT by Trevor Cordes
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version: Current
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-28 16:04:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
audit trace during an incoming voice call (11.04 KB, text/plain)
2006-07-11 16:37 EDT, Trevor Cordes
no flags Details
audit trace during an incoming FAX call and custom script run (5.93 KB, text/plain)
2006-07-11 17:03 EDT, Trevor Cordes
no flags Details
revamped audit trace of voicemail after I simplified my script to only use /var/spool/voice/incoming (3.64 KB, text/plain)
2006-07-11 17:10 EDT, Trevor Cordes
no flags Details

  None (edit)
Description Trevor Cordes 2006-07-04 05:38:46 EDT
Description of problem:

selinux breaks vgetty.  I've run vgetty in FC1, 2 and 3 for years
(selinux=warn).  Just upgraded (fresh install) to FC5 with selinux=enforced. 
vgetty appears to be policed by selinux (should it be??), perhaps because it's
an offshoot of mgetty, which may be enforced properly.

When starting vgetty from inittab:

Jul  4 04:31:07 pog kernel: audit(1152005467.951:917): avc:  denied  { append }
for  pid=5758 comm="vgetty" name="vgetty.log.ttyS0" dev=dm-0 ino=2000380
scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:var_log_t:s0
tclass=file

When an incoming call is received:

Jul  4 04:42:02 pog kernel: audit(1152006122.484:918): avc:  denied  { search }
for  pid=5758 comm="vgetty" name="spool" dev=dm-0 ino=1998889
scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:var_spool_t:s0
tclass=dir
Jul  4 04:42:02 pog kernel: audit(1152006122.484:919): avc:  denied  { append }
for  pid=5758 comm="vgetty" name="vgetty.log.ttyS0" dev=dm-0 ino=2000380
scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:var_log_t:s0
tclass=file
Jul  4 04:42:14 pog kernel: audit(1152006134.485:920): avc:  denied  { search }
for  pid=5758 comm="vgetty" name="spool" dev=dm-0 ino=1998889
scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:var_spool_t:s0
tclass=dir
Jul  4 04:42:15 pog kernel: audit(1152006135.321:921): avc:  denied  { setgid }
for  pid=5758 comm="vgetty" capability=6 scontext=system_u:system_r:getty_t:s0
tcontext=system_u:system_r:getty_t:s0 tclass=capability
Jul  4 04:42:16 pog kernel: audit(1152006136.973:922): avc:  denied  { setgid }
for  pid=5758 comm="vgetty" capability=6 scontext=system_u:system_r:getty_t:s0
tcontext=system_u:system_r:getty_t:s0 tclass=capability
Jul  4 04:42:16 pog kernel: audit(1152006136.973:923): avc:  denied  { append }
for  pid=5885 comm="vgetty" name="vgetty.log.ttyS0" dev=dm-0 ino=2000380
scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:var_log_t:s0
tclass=file

Since vgetty is very complex and runs a few user-defined scripts to process
received voice calls, I don't see how it can be selinux protected.  Perhaps it
was not intended to be?

If it is to be selinux protected, obviously some major work needs to be done.  I
can help test selinux changes if that helps, but I don't know anything about
playing with selinux myself.

Is there a way in the meantime I can turn off selinux just for vgetty (and leave
it on for all other daemons)?


Version-Release number of selected component (if applicable):
mgetty-voice-1.1.33-7.FC5.2

How reproducible:
Always


Steps to Reproduce:
1. install FC5 with selinux enforced
2. try to get vgetty working
  
Actual results:
audit avc denied errors

Expected results:
vgetty should work, voice calls should be received
Comment 1 Daniel Walsh 2006-07-11 13:58:51 EDT
First your log file is labeled incorrectly.

restorecon /var/log/vgetty.log.*

What is it trying to do with /var/spool?  Does it have a file it keeps there?
I will add the ability to search /var/spool (It should be there anyways.)
Can you do a setenforce 0

and then grab all of the avc messages?
Comment 2 Daniel Walsh 2006-07-11 14:02:37 EDT
Added /var/spool/voice and other fixes in selinux-policy-2.3.2-2 in rawhide. 
This will show up in the next test policy release for FC5.
Comment 3 Trevor Cordes 2006-07-11 16:35:45 EDT
restorecon doesn't do anything as vgetty is not in the targeted regexp file,
from what I can tell; only mgetty.log.* is in there.

#ll -Z /var/log/vgetty.log.ttyS0
-rw-r--r--  root root system_u:object_r:var_log_t      /var/log/vgetty.log.ttyS0
#restorecon /var/log/vgetty.log.*
#ll -Z /var/log/vgetty.log.ttyS0
-rw-r--r--  root root system_u:object_r:var_log_t      /var/log/vgetty.log.ttyS0

/var/spool/voice is where the playback message, as well as the recorded messages go.

Also, I have a script that vgetty calls when faxes are received that then places
converted faxes into an NFS mount.  Same with voice messages.  I take it I'll
have to modify my scripts to use only those directories which are explicitly
allowed by selinux, like /var/spool/voice?  Or are the child processes (my
scripts) of vgetty exempt from selinux policies?  (Having a script to handle new
voicemail & faxes is standard mgetty/vgetty procedure, so I'm not doing anything
weird here.)

Comment 4 Trevor Cordes 2006-07-11 16:37:01 EDT
Created attachment 132266 [details]
audit trace during an incoming voice call
Comment 5 Trevor Cordes 2006-07-11 17:03:40 EDT
Created attachment 132267 [details]
audit trace during an incoming FAX call and custom script run
Comment 6 Trevor Cordes 2006-07-11 17:10:58 EDT
Created attachment 132268 [details]
revamped audit trace of voicemail after I simplified my script to only use /var/spool/voice/incoming
Comment 7 Daniel Walsh 2007-03-28 16:04:11 EDT
Closing bugs

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