Bug 472435 - SELinux is preventing cupsd (cupsd_t) ["write" ,"rename"] cupsd_etc_t
SELinux is preventing cupsd (cupsd_t) ["write" ,"rename"] cupsd_etc_t
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-20 15:18 EST by Jonathan Underwood
Modified: 2009-01-08 14:06 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-08 14:06:45 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 Jonathan Underwood 2008-11-20 15:18:33 EST
Description of problem:
Printing a document from evince just triggered a deluge of AVC denials of two types:

Nov 20 20:10:42 clfelspc001 setroubleshoot: SELinux is preventing cupsd (cupsd_t) "write" cupsd_etc_t. For complete SELinux messages. run sealert -l 6fab4aa4-75b9-4463-b991-f38e4d4e864e

Nov 20 20:10:43 clfelspc001 setroubleshoot: SELinux is preventing cupsd (cupsd_t) "rename" cupsd_etc_t. For complete SELinux messages. run sealert -l 2624bdb9-d54c-4123-91e5-f38d8f10514a

this is having downloaded the document in firefox which fired up evince (if that's relevant). Details denial messages below.


# sealert -l 6fab4aa4-75b9-4463-b991-f38e4d4e864e

Summary:

SELinux is preventing cupsd (cupsd_t) "write" cupsd_etc_t.

Detailed Description:

SELinux denied access requested by cupsd. It is not expected that this access is
required by cupsd and this access may signal an intrusion attempt. It is also
possible that the specific version or configuration of the application is
causing it to require additional access.

Allowing Access:

You can generate a local policy module to allow this access - see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable
SELinux protection altogether. Disabling SELinux protection is not recommended.
Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against this package.

Additional Information:

Source Context                system_u:system_r:cupsd_t:s0-s0:c0.c1023
Target Context                unconfined_u:object_r:cupsd_etc_t:s0
Target Objects                ./subscriptions.conf [ file ]
Source                        cupsd
Source Path                   /usr/sbin/cupsd
Port                          <Unknown>
Host                          clfelspc001.dc.clf.rl.ac.uk
Source RPM Packages           cups-1.3.9-1.fc9
Target RPM Packages           
Policy RPM                    selinux-policy-3.3.1-107.fc9
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   catchall
Host Name                     clfelspc001.dc.clf.rl.ac.uk
Platform                      Linux clfelspc001.dc.clf.rl.ac.uk
                              2.6.27.5-41.fc9.x86_64 #1 SMP Thu Nov 13 20:29:07
                              EST 2008 x86_64 x86_64
Alert Count                   77
First Seen                    Thu Nov 20 20:06:57 2008
Last Seen                     Thu Nov 20 20:07:08 2008
Local ID                      6fab4aa4-75b9-4463-b991-f38e4d4e864e
Line Numbers                  

Raw Audit Messages            

host=clfelspc001.dc.clf.rl.ac.uk type=AVC msg=audit(1227211628.642:858): avc:  denied  { write } for  pid=2733 comm="cupsd" name="subscriptions.conf" dev=dm-0 ino=25250 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:cupsd_etc_t:s0 tclass=file

host=clfelspc001.dc.clf.rl.ac.uk type=SYSCALL msg=audit(1227211628.642:858): arch=c000003e syscall=2 success=no exit=-13 a0=7fffd1103ae0 a1=241 a2=1b6 a3=632e736e6f697470 items=0 ppid=1 pid=2733 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="cupsd" exe="/usr/sbin/cupsd" subj=system_u:system_r:cupsd_t:s0-s0:c0.c1023 key=(null)




# sealert -l 2624bdb9-d54c-4123-91e5-f38d8f10514a

Summary:

SELinux is preventing cupsd (cupsd_t) "rename" cupsd_etc_t.

Detailed Description:

SELinux denied access requested by cupsd. It is not expected that this access is
required by cupsd and this access may signal an intrusion attempt. It is also
possible that the specific version or configuration of the application is
causing it to require additional access.

Allowing Access:

You can generate a local policy module to allow this access - see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable
SELinux protection altogether. Disabling SELinux protection is not recommended.
Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against this package.

Additional Information:

Source Context                system_u:system_r:cupsd_t:s0-s0:c0.c1023
Target Context                unconfined_u:object_r:cupsd_etc_t:s0
Target Objects                ./subscriptions.conf.O [ file ]
Source                        cupsd
Source Path                   /usr/sbin/cupsd
Port                          <Unknown>
Host                          clfelspc001.dc.clf.rl.ac.uk
Source RPM Packages           cups-1.3.9-1.fc9
Target RPM Packages           
Policy RPM                    selinux-policy-3.3.1-107.fc9
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   catchall
Host Name                     clfelspc001.dc.clf.rl.ac.uk
Platform                      Linux clfelspc001.dc.clf.rl.ac.uk
                              2.6.27.5-41.fc9.x86_64 #1 SMP Thu Nov 13 20:29:07
                              EST 2008 x86_64 x86_64
Alert Count                   77
First Seen                    Thu Nov 20 20:06:57 2008
Last Seen                     Thu Nov 20 20:07:08 2008
Local ID                      2624bdb9-d54c-4123-91e5-f38d8f10514a
Line Numbers                  

Raw Audit Messages            

host=clfelspc001.dc.clf.rl.ac.uk type=AVC msg=audit(1227211628.642:859): avc:  denied  { rename } for  pid=2733 comm="cupsd" name="subscriptions.conf.O" dev=dm-0 ino=25082 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:cupsd_etc_t:s0 tclass=file

host=clfelspc001.dc.clf.rl.ac.uk type=SYSCALL msg=audit(1227211628.642:859): arch=c000003e syscall=82 success=no exit=-13 a0=7fffd11036e0 a1=7fffd1103ae0 a2=1 a3=6e6f632e736e6f69 items=0 ppid=1 pid=2733 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="cupsd" exe="/usr/sbin/cupsd" subj=system_u:system_r:cupsd_t:s0-s0:c0.c1023 key=(null)




Version-Release number of selected component (if applicable):


selinux-policy-3.3.1-107.fc9.noarch
libselinux-python-2.0.67-4.fc9.x86_64
libselinux-2.0.67-4.fc9.x86_64
selinux-policy-devel-3.3.1-107.fc9.noarch
libselinux-2.0.67-4.fc9.i386
selinux-policy-targeted-3.3.1-107.fc9.noarch


cups-1.3.9-1.fc9.x86_64
cupsddk-drivers-1.2.3-4.fc9.x86_64
cups-libs-1.3.9-1.fc9.i386
libgnomecups-0.2.3-3.fc9.x86_64
hpijs-2.8.2-2.fc9.x86_64


How reproducible:
Everytime

Steps to Reproduce:
1.Print a document from evince
2.
3.
  
Actual results:
AVC denials

Expected results:
No AVS denials

Additional info:
Comment 1 Daniel Walsh 2008-11-20 16:51:09 EST
Mislabeled files

# restorecon -R -v /etc/cups

Will fix.

Any idea how these files got created?
Comment 2 Warren Togami 2008-11-20 16:52:47 EST
I saw this on my F10 system after it was upgraded from F9.
Comment 3 Daniel Walsh 2008-11-20 16:54:38 EST
type=ANOM_ABEND msg=audit(11/20/08 14:47:38.430:12) : auid=unset uid=root gid=root ses=4294967295 subj=root:system_r:rpm_t:s0 pid=15372 comm=rpmq sig=Floating point exception
Comment 4 Jonathan Underwood 2008-11-20 18:59:48 EST
(In reply to comment #1)
> Mislabeled files
> 
> # restorecon -R -v /etc/cups
> 
> Will fix.
> 
> Any idea how these files got created?

Well, they're owned by cups, but system-config-printers writes to some of them, and that is what I used to configure the printers. In case it is helpful:

# ls -lRZ /etc/cups
/etc/cups:
-rw-------  root lp system_u:object_r:cupsd_rw_etc_t:s0 classes.conf
-rw-------  root lp system_u:object_r:cupsd_rw_etc_t:s0 classes.conf.O
-rw-r--r--  root lp system_u:object_r:etc_t:s0       client.conf
-rw-r-----  root lp system_u:object_r:cupsd_rw_etc_t:s0 cupsd.conf
-rw-r-----  root lp system_u:object_r:cupsd_rw_etc_t:s0 cupsd.conf.default
drwxr-xr-x  root root system_u:object_r:cupsd_etc_t:s0 interfaces
-rw-r--r--  root lp system_u:object_r:cupsd_rw_etc_t:s0 lpoptions
-rw-r--r--  root root system_u:object_r:cupsd_etc_t:s0 mime.convs
-rw-r--r--  root root system_u:object_r:cupsd_etc_t:s0 mime.types
-rw-r--r--  root lp system_u:object_r:cupsd_etc_t:s0 pdftops.conf
drwxr-xr-x  root lp system_u:object_r:cupsd_etc_t:s0 ppd
-rw-------  root lp unconfined_u:object_r:cupsd_rw_etc_t:s0 printers.conf
-rw-------  root lp system_u:object_r:cupsd_rw_etc_t:s0 printers.conf.O
-rw-r--r--  root root system_u:object_r:cupsd_etc_t:s0 pstoraster.convs
-rw-r--r--  root lp system_u:object_r:cupsd_etc_t:s0 snmp.conf
drwx------  root lp system_u:object_r:cupsd_etc_t:s0 ssl
-rw-r-----  root lp unconfined_u:object_r:cupsd_etc_t:s0 subscriptions.conf
-rw-r-----  root lp unconfined_u:object_r:cupsd_etc_t:s0 subscriptions.conf.O

/etc/cups/interfaces:

/etc/cups/ppd:
-rw-r--r--  root root system_u:object_r:cupsd_rw_etc_t:s0 HP4300.ppd

/etc/cups/ssl:
Comment 5 Tim Waugh 2008-11-21 06:25:38 EST
(In reply to comment #4)
> Well, they're owned by cups, but system-config-printers writes to some of them,
> and that is what I used to configure the printers.

Actually system-config-printer tells cupsd to alter them, it doesn't write to them directly.

The interesting thing is that /etc/cups/subscriptions.conf has 'unconfined_u' there, and so does printers.conf.  Were these files hand-edited (say, with vi or whatever) at any point?

Or alternatively, was cupsd ever restarted from an "unusual" security context (e.g. 'sudo su -' in a VNC session)?
Comment 6 Jonathan Underwood 2008-11-21 06:43:33 EST
(In reply to comment #5)
> The interesting thing is that /etc/cups/subscriptions.conf has 'unconfined_u'
> there, and so does printers.conf.  Were these files hand-edited (say, with vi
> or whatever) at any point?
> 

I can definitely say I have never hand edited any of those files.

> Or alternatively, was cupsd ever restarted from an "unusual" security context
> (e.g. 'sudo su -' in a VNC session)?

Nope, cups has only ever been started at boot on this particular machine.

HTH.
Comment 7 Daniel Walsh 2008-11-21 08:24:03 EST
unconfined_u:object_r:cupsd_etc_t:s0 subscriptions.conf.O

This means some app launched by an unconfined_u user modified the file.  I would suspect system-config-* or a package install via yum or rpm.
Comment 8 Tim Waugh 2008-11-21 08:33:00 EST
system-config-printer does not touch files in /etc/cups itself, so yum/rpm sounds like the culprit.  Currently trying to reproduce the problem with a F9->F10 upgrade.
Comment 9 Jonathan Underwood 2008-11-21 08:43:26 EST
Not sure if this is a clue:

rpm -q --whatprovides /etc/cups/*
cups-1.3.9-1.fc9.x86_64
file /etc/cups/classes.conf.O is not owned by any package
cups-1.3.9-1.fc9.x86_64
cups-1.3.9-1.fc9.x86_64
cups-1.3.9-1.fc9.x86_64
cups-1.3.9-1.fc9.x86_64
cups-1.3.9-1.fc9.x86_64
cups-1.3.9-1.fc9.x86_64
cups-1.3.9-1.fc9.x86_64
cups-1.3.9-1.fc9.x86_64
cups-1.3.9-1.fc9.x86_64
cups-1.3.9-1.fc9.x86_64
file /etc/cups/printers.conf.O is not owned by any package
cups-1.3.9-1.fc9.x86_64
cups-1.3.9-1.fc9.x86_64
cups-1.3.9-1.fc9.x86_64
cups-1.3.9-1.fc9.x86_64
file /etc/cups/subscriptions.conf.O is not owned by any package


Perhaps whatever is moving the *.conf to *.conf.0 is the culprit. I don't know what is doing that though.
Comment 10 Jonathan Underwood 2008-11-21 08:46:32 EST
(In reply to comment #5)
> Or alternatively, was cupsd ever restarted from an "unusual" security context
> (e.g. 'sudo su -' in a VNC session)?

Hm, maybe I misunderstood this question, so to be clear: On the machine in question I do frequently use a VNC client (vinagre) to connect to remote (F-9) machines. On the machine in question I have not run a VNC server, ever. (I think the latter point is what you were asking, but I wasn't 100 percent sure.)
Comment 11 Daniel Walsh 2008-11-21 08:58:08 EST
There is a chance cups could be running as unconfined_u, my earlier statement is false.

# service cups restart
Stopping cups:                                             [  OK  ]
Starting cups:                                             [  OK  ]
You have new mail in /var/spool/mail/root
# ps -eZ | grep cups
unconfined_u:system_r:cupsd_t:SystemLow-SystemHigh 3103 ? 00:00:00 cupsd
unconfined_u:system_r:cupsd_t:SystemLow-SystemHigh 3104 ? 00:00:00 cups-polld
unconfined_u:system_r:cupsd_t:SystemLow-SystemHigh 3105 ? 00:00:00 cups-polld


Now if a process running as cupsd_t, cupsd_config_t, or cupsd_lpd_t created the file it would be labeled cups_rw_etc_t as it should.  All other confined domains would not be allowed to create the file if running in enforcing mode.  An unconfined domain (unconfined_t, rpm_t, initrc_t) could create the file and it would be labeled cups_etc_t.  THe setroubleshoot indicates the machine was run in enforcing mode.  Did you run the machine in permissive mode?
Comment 12 Tim Waugh 2008-11-21 09:07:05 EST
(In reply to comment #9)
> Perhaps whatever is moving the *.conf to *.conf.0 is the culprit. I don't know
> what is doing that though.

That's cupsd, but it just renames conf -> conf.O when writing a new conf file.  Newly created files will have the correct context when created by cupsd due to policy.
Comment 13 Tim Waugh 2008-11-21 09:07:48 EST
(In reply to comment #10)
> Hm, maybe I misunderstood this question, so to be clear: On the machine in
> question I do frequently use a VNC client (vinagre) to connect to remote (F-9)
> machines. On the machine in question I have not run a VNC server, ever. (I
> think the latter point is what you were asking, but I wasn't 100 percent sure.)

Yes, my question was about running a VNC server, as that runs in an "unusual" security context (unconfined_u:system_r:unconfined_notrans_t:s0).
Comment 14 Tim Waugh 2008-11-21 09:12:29 EST
(In reply to comment #11)
> There is a chance cups could be running as unconfined_u, my earlier statement
> is false.

Ah, OK.  It still seems to be a mystery how those files are getting cupsd_etc_t instead of cupsd_rw_etc_t though.  My F9->F10 upgrade has finished, and I don't see the problem here.  /etc/cups/*.conf all have the correct file context.

Warren: how did you perform the upgrade?  Booting an ISO?
Comment 15 Jonathan Underwood 2008-11-21 09:17:36 EST
(In reply to comment #12)
> (In reply to comment #9)
> > Perhaps whatever is moving the *.conf to *.conf.0 is the culprit. I don't know
> > what is doing that though.
> 
> That's cupsd, but it just renames conf -> conf.O when writing a new conf file. 
> Newly created files will have the correct context when created by cupsd due to
> policy.

Oh, right, OK. [As an aside, the cups package should probably own the .0 files so they're cleaned up on removal of cups?].
Comment 16 Jonathan Underwood 2008-11-21 09:18:51 EST
(In reply to comment #11)
[snip]
> run in enforcing mode.  Did you run the machine in permissive mode?

AFAIK I have left the machine in enforcing mode since day 1 of the F-9 install.
Comment 17 Daniel Walsh 2008-11-21 14:35:24 EST
If you ran a vncserver and restarted cups you could get this problem.

login via vnc, su to root, service restart cups, do something to  cause the subscripttions file to get recreated.
Comment 18 Jonathan Underwood 2008-11-21 15:51:50 EST
(In reply to comment #17)
> If you ran a vncserver and restarted cups you could get this problem.
> 
> login via vnc, su to root, service restart cups, do something to  cause the
> subscripttions file to get recreated.

Yup, definitely never did that. :)
Comment 19 Daniel Walsh 2009-01-08 14:06:45 EST
Well if it comes back reopen the bug.

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