AVC when configuring printer.....

[Tom London]

Running latest Rawhide, targeted/enforcing.

System->Administration->Printing, and hitting 'Apply' on the currently
configured printer produces the following:

----
type=PATH msg=audit(02/27/2006 08:04:15.126:101) : item=2
flags=follow,open inode=1045697 dev=fd:00 mode=file,755 ouid=root
ogid=root rdev=00:00
type=PATH msg=audit(02/27/2006 08:04:15.126:101) : item=1
flags=follow,open inode=5786615 dev=fd:00 mode=file,755 ouid=root
ogid=root rdev=00:00
type=PATH msg=audit(02/27/2006 08:04:15.126:101) : item=0
name=/usr/sbin/printconf-backend flags=follow,open inode=5790576
dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00
type=CWD msg=audit(02/27/2006 08:04:15.126:101) :  cwd=/
type=AVC_PATH msg=audit(02/27/2006 08:04:15.126:101) :  path=pipe:[21844]
type=AVC_PATH msg=audit(02/27/2006 08:04:15.126:101) : 
path=/root/.rh-fontconfig/.fonts.cache-2
type=SYSCALL msg=audit(02/27/2006 08:04:15.126:101) : arch=i386
syscall=execve success=yes exit=0 a0=899cdc8 a1=899ce18 a2=899cf20
a3=8999d70 items=3 pid=5773 auid=tbl uid=root gid=root euid=root
suid=root fsuid=root egid=root sgid=root fsgid=root
comm=printconf-backe exe=/usr/bin/python
type=AVC msg=audit(02/27/2006 08:04:15.126:101) : avc:  denied  { read
} for  pid=5773 comm=printconf-backe name=.fonts.cache-2 dev=dm-0
ino=555510 scontext=system_u:system_r:cupsd_config_t:s0
tcontext=system_u:object_r:user_home_t:s0 tclass=file
type=AVC msg=audit(02/27/2006 08:04:15.126:101) : avc:  denied  {
write } for  pid=5773 comm=printconf-backe name=[21844] dev=pipefs
ino=21844 scontext=system_u:system_r:cupsd_config_t:s0
tcontext=system_u:system_r:unconfined_t:s0 tclass=fifo_file
----

tom
--
Tom London

[Ivan Gyurdiev]

>  type=AVC msg=audit(02/27/2006 08:04:15.126:101) : avc:  denied  {
> read
>  } for  pid=5773 comm=printconf-backe name=.fonts.cache-2 dev=dm-0
>  ino=555510 scontext=system_u:system_r:cupsd_config_t:s0
>  tcontext=system_u:object_r:user_home_t:s0 tclass=file
>     
Does it work? This is likely harmless.
However, we should be making use of the fact that this file 
(.fonts.cache-2) is now in its own directory. I specifically filed a bug 
to get it moved, and now we should write policy to take advantage of 
that, by:

- prelabeling this folder with the correct type in our profile script, 
or any future solution, so that the cache can be created with the 
correct type by libfontconfig

- allowing programs that need to read fonts to read that type
   (moving font-related macros from the old strict policy into the new 
refpol).

It's unfortunate all those problems were solved in the old strict 
policy, and now they all have to be re-solved for refpol.

>  type=AVC msg=audit(02/27/2006 08:04:15.126:101) : avc:  denied  {
>  write } for  pid=5773 comm=printconf-backe name=[21844] dev=pipefs
>  ino=21844 scontext=system_u:system_r:cupsd_config_t:s0
>  tcontext=system_u:system_r:unconfined_t:s0 tclass=fifo_file
>     
This isn't very helpful - what is it trying to write to - grep for 21844.
(Does lsof show that number?)

[Tom London]

On 3/2/06, Ivan Gyurdiev <ivg2(a)cornell.edu&gt; wrote:
>  > type=AVC msg=audit(02/27/2006 08:04:15.126:101) : avc:  denied  { read
>  > } for  pid=5773 comm=printconf-backe name=.fonts.cache-2 dev=dm-0
>  > ino=555510 scontext=system_u:system_r:cupsd_config_t:s0
>  > tcontext=system_u:object_r:user_home_t:s0 tclass=file
>  >
>  Does it work? This is likely harmless.
>  However, we should be making use of the fact that this file
>  (.fonts.cache-2) is now in its own directory. I specifically filed a bug
>  to get it moved, and now we should write policy to take advantage of
>  that, by:
>
>  - prelabeling this folder with the correct type in our profile script,
>  or any future solution, so that the cache can be created with the
>  correct type by libfontconfig
>
>  - allowing programs that need to read fonts to read that type
>     (moving font-related macros from the old strict policy into the new
>  refpol).
>
>  It's unfortunate all those problems were solved in the old strict
>  policy, and now they all have to be re-solved for refpol.
>
>  > type=AVC msg=audit(02/27/2006 08:04:15.126:101) : avc:  denied  {
>  > write } for  pid=5773 comm=printconf-backe name=[21844] dev=pipefs
>  > ino=21844 scontext=system_u:system_r:cupsd_config_t:s0
>  > tcontext=system_u:system_r:unconfined_t:s0 tclass=fifo_file
>  >
>  This isn't very helpful - what is it trying to write to - grep for 21844.
>  (Does lsof show that number?)
>
>  
Sorry for the lack of specifics here, but it was all I could get at the time.

Didn't think about 'grep XX | lsof'.

Recreating yields:

type=AVC msg=audit(1141332960.725:64): avc:  denied  { write } for 
pid=8214 comm="printconf-backe" name="[48007]" dev=pipefs ino=48007
scontext=system_u:system_r:cupsd_config_t:s0
tcontext=system_u:system_r:unconfined_t:s0 tclass=fifo_filetype=AVC
msg=audit(1141332960.725:64): avc:  denied  { write } for  pid=8214
comm="printconf-backe" name="[48008]" dev=pipefs ino=48008
scontext=system_u:system_r:cupsd_config_t:s0
tcontext=system_u:system_r:unconfined_t:s0 tclass=fifo_filetype=AVC
msg=audit(1141332960.725:64): avc:  denied  { write } for  pid=8214
comm="printconf-backe" name="[48009]" dev=pipefs ino=48009
scontext=system_u:system_r:cupsd_config_t:s0
tcontext=system_u:system_r:unconfined_t:s0 tclass=fifo_filetype=AVC
msg=audit(1141332960.725:64): avc:  denied  { read } for  pid=8214
comm="printconf-backe" name=".fonts.cache-2" dev=dm-0 ino=555510
scontext=system_u:system_r:cupsd_config_t:s0
tcontext=system_u:object_r:user_home_t:s0 tclass=file
type=SYSCALL msg=audit(1141332960.725:64): arch=40000003 syscall=11
success=yes exit=0 a0=9029dc8 a1=9029e18 a2=9029f20 a3=9026d70 items=3
pid=8214 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 comm="printconf-backe" exe="/usr/bin/python"
type=AVC_PATH msg=audit(1141332960.725:64): 
path="/root/.rh-fontconfig/.fonts.cache-2"
type=AVC_PATH msg=audit(1141332960.725:64):  path="pipe:[48009]"
type=AVC_PATH msg=audit(1141332960.725:64):  path="pipe:[48008]"
type=AVC_PATH msg=audit(1141332960.725:64):  path="pipe:[48007]"
type=CWD msg=audit(1141332960.725:64):  cwd="/"
type=PATH msg=audit(1141332960.725:64): item=0
name="/usr/sbin/printconf-backend" flags=101  inode=5790576 dev=fd:00
mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1141332960.725:64): item=1 flags=101 
inode=5786615 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1141332960.725:64): item=2 flags=101 
inode=1045697 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00

'lsof | grep 4800' yields:

[root@localhost ~]# lsof | grep 4800
Xorg      2494      root   35u     unix 0xf6e48004                
48012 /tmp/.X11-unix/X0
gnome-scr 2770       tbl   14u     unix 0xf0b48004                 23919 socket
firefox-b 2822       tbl   34u      REG      253,0    2048000   
6928883 /home/tbl/.mozilla/firefox/bdyi67iu.default/Cache/_CACHE_003_
printconf 8186      root    6r     FIFO        0,5                 48007 pipe
printconf 8186      root    7w     FIFO        0,5                 48007 pipe
printconf 8186      root    8r     FIFO        0,5                 48008 pipe
printconf 8186      root    9w     FIFO        0,5                 48008 pipe
printconf 8186      root   10r     FIFO        0,5                 48009 pipe
printconf 8186      root   11w     FIFO        0,5                 48009 pipe
[root@localhost ~]#

So these are all printconf pipes.   What other info can I provide?

Trivial test of just 'applying' the existing config appears not to
break anything. So, this could be harmless....

tom
--
Tom London

[Ivan Gyurdiev]

>  So these are all printconf pipes. 
Printconf runs in
unconfined_t, and printconf-backend runs in 
cupsd_config_t (not sure if they should be setup like that, I suspect 
this might have been done to restrict what can acccess the cupsd 
domains). It seems they need to communicate via pipes. Looking at the 
current policy, rules are already in place [ for targeted ] to allow 
reading unconfined pipes from cupsd_config_t, but no rules exist for 
writing data back to unconfined pipes (communication in the other 
direction).

Either printconf should be moved into cupsd_config_t too.... or 
cupsd_config_t should be allowed to write as well as read from 
unconfined pipes.

>  Trivial test of just 'applying' the existing config appears
> not to
>  break anything. So, this could be harmless....
>     
That usually means we haven't found out what the problem is yet, and 
it's non-fatal (which doesn't necessarily mean harmless).

[Tom London]

On 3/3/06, Ivan Gyurdiev <ivg2(a)cornell.edu&gt; wrote:
>  > So these are all printconf pipes.
>  Printconf runs in unconfined_t, and printconf-backend runs in
>  cupsd_config_t (not sure if they should be setup like that, I suspect
>  this might have been done to restrict what can acccess the cupsd
>  domains). It seems they need to communicate via pipes. Looking at the
>  current policy, rules are already in place [ for targeted ] to allow
>  reading unconfined pipes from cupsd_config_t, but no rules exist for
>  writing data back to unconfined pipes (communication in the other
>  direction).
>
>  Either printconf should be moved into cupsd_config_t too.... or
>  cupsd_config_t should be allowed to write as well as read from
>  unconfined pipes.
>
>  > Trivial test of just 'applying' the existing config appears not to
>  > break anything. So, this could be harmless....
>  >
>  That usually means we haven't found out what the problem is yet, and
>  it's non-fatal (which doesn't necessarily mean harmless).
>  
Ivan,

I agree: non-fatal is not the same as harmless.

Thanks for taking the time to analyze this.

tom
--
Tom London