cups... new avcs?

[Tom London]

I noticed what I think are new avcs coming from starting cups:

Aug  1 13:49:59 fedora kernel: audit(1091393399.153:0): avc:  denied  { 
write }
for  pid=2117 exe=/usr/bin/python name=util dev=hda2 ino=4309019 
scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usr_t 
tclass=dir
Aug  1 13:49:59 fedora kernel: audit(1091393399.432:0): avc:  denied  { 
write }
for  pid=2117 exe=/usr/bin/python name=util dev=hda2 ino=4309019 
scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usr_t 
tclass=dir

ino#4309019 is /usr/share/printconf/util
(not sure why cups wants to write there ....)

tom

[Russell Coker]

On Mon, 2 Aug 2004 07:00, Tom London <selinux(a)comcast.net&gt; wrote:
>  I noticed what I think are new avcs coming from starting cups:
>
>  Aug  1 13:49:59 fedora kernel: audit(1091393399.153:0): avc:  denied  {
>  write }
>  for  pid=2117 exe=/usr/bin/python name=util dev=hda2 ino=4309019
>  scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usr_t
>  tclass=dir
>
>  ino#4309019 is /usr/share/printconf/util
>  (not sure why cups wants to write there ....) 
What is under that directory tree?

What does cups do in this situation if you put the machine in permissive mode 
and do the same print operation?

Naturally we can't give cups access to usr_t.  We could use a different label 
for the directory in question as an interim measure.  But I think that this 
is really a bug in cups.  I don't think that there's any good reason for cups 
to be writing there.  I think that systems with a /usr file system mounted 
read-only should work fine as print servers!

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

[Tom London]

Agree regarding read-only /usr setups.  Looks like
cups is writing a python file called
/usr/share/printconf/util/backend.pyo.

Here are avc's from a permissive boot
(sorry I forgot to include in original message):
Aug  2 07:33:27 fedora kernel: audit(1091457207.688:0): avc:  denied  { 
write }
for  pid=1997 exe=/usr/bin/python name=util dev=hda2 ino=4309019 
scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usr_t 
tclass=dir
Aug  2 07:33:27 fedora kernel: audit(1091457207.689:0): avc:  denied  { 
remove_name } for  pid=1997 exe=/usr/bin/python name=backend.pyo 
dev=hda2 ino=4309038 scontext=system_u:system_r:cupsd_t 
tcontext=system_u:object_r:usr_t tclass=dir
Aug  2 07:33:27 fedora kernel: audit(1091457207.726:0): avc:  denied  { 
add_name } for  pid=1997 exe=/usr/bin/python name=backend.pyo 
scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usr_t 
tclass=dir
Aug  2 07:33:27 fedora kernel: audit(1091457207.726:0): avc:  denied  { 
create } for  pid=1997 exe=/usr/bin/python name=backend.pyo 
scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usr_t 
tclass=file
Aug  2 07:33:27 fedora kernel: audit(1091457207.728:0): avc:  denied  { 
write }
for  pid=1997 exe=/usr/bin/python 
path=/usr/share/printconf/util/backend.pyo dev=hda2 ino=4309038 
scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usr_t 
tclass=file

Sigh....
[/usr/share/printconf/util/ contains a bunch of python .py
and .pyo files, a file named 'smbprint', and a file named
'strip_control_file.sh'.  All the files are labeled
system_u:object_r:printconf_t, except for one named
'print.py'. It is labeled system_u:object_r:bin_t.]

I'll file a bugzilla against cups for this....
    tom

Russell Coker wrote:

> On Mon, 2 Aug 2004 07:00, Tom London <selinux(a)comcast.net&gt;
> wrote:
>   
>
> >I noticed what I think are new avcs coming from starting cups:
> >
> >Aug  1 13:49:59 fedora kernel: audit(1091393399.153:0): avc:  denied  {
> >write }
> >for  pid=2117 exe=/usr/bin/python name=util dev=hda2 ino=4309019
> >scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:usr_t
> >tclass=dir
> >
> >ino#4309019 is /usr/share/printconf/util
> >(not sure why cups wants to write there ....)
> >    
> >
>
> What is under that directory tree?
>
> What does cups do in this situation if you put the machine in permissive mode 
> and do the same print operation?
>
> Naturally we can't give cups access to usr_t.  We could use a different label 
> for the directory in question as an interim measure.  But I think that this 
> is really a bug in cups.  I don't think that there's any good reason for cups 
> to be writing there.  I think that systems with a /usr file system mounted 
> read-only should work fine as print servers!
>
>   
>

[Russell Coker]

On Tue, 3 Aug 2004 00:41, Tom London <selinux(a)comcast.net&gt; wrote:
>  Sigh....
>  [/usr/share/printconf/util/ contains a bunch of python .py
>  and .pyo files, a file named 'smbprint', and a file named
>  'strip_control_file.sh'.  All the files are labeled
>  system_u:object_r:printconf_t, except for one named
>  'print.py'. It is labeled system_u:object_r:bin_t.]
>
>  I'll file a bugzilla against cups for this.... 
I think that this is the correct thing to do.  No matter what the reason for 
writing the file, /usr/share is not the place for it.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

[Tim Waugh]

On Wed, Aug 04, 2004 at 09:17:59PM +1000, Russell Coker wrote:

>  On Tue, 3 Aug 2004 00:41, Tom London <selinux(a)comcast.net&gt;
> wrote:
>  > Sigh....
>  > [/usr/share/printconf/util/ contains a bunch of python .py
>  > and .pyo files, a file named 'smbprint', and a file named
>  > 'strip_control_file.sh'.  All the files are labeled
>  > system_u:object_r:printconf_t, except for one named
>  > 'print.py'. It is labeled system_u:object_r:bin_t.]
>  >
>  > I'll file a bugzilla against cups for this....
>  
>  I think that this is the correct thing to do.  No matter what the reason for 
>  writing the file, /usr/share is not the place for it. 
CUPS doesn't own any of these files -- system-config-printer does, and
some of its components run as cupsd_t.

The problem concerning .pyo and .pyc files is a general one -- these
should be shipped in the RPM packages, but we need a general method
for doing that as it is not trivial.

Tim.
*/