[refpolicy] write AVC on access()?

[dac.override@gmail.com (Dominick Grift)]

On Mon, Sep 08, 2014 at 09:23:24AM +0200, Pierre Ossman wrote:
> Hi,
> 
> I have a problem that our software is causing these on (at least)
> Fedora and RHEL:
> 
> > type=AVC msg=audit(1409929323.649:42767): avc:  denied  { write } for  pid=31220 comm="python-thinlinc" name="thinlinc.hconf" dev="dm-0" ino=2756323 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:usr_t:s0 tclass=file
> > type=SYSCALL msg=audit(1409929323.649:42767): arch=c000003e syscall=21 success=yes exit=0 a0=db4c70 a1=2 a2=33925bff88 a3=0 items=0 ppid=29722 pid=31220 auid=210 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts7 ses=2 comm="python-thinlinc" exe="/usr/bin/python2.7" subj=system_u:system_r:cupsd_t:s0-s0:c0.c1023 key=(null)
> 
> Syscall 21 is access() if I'm reading things correctly, and we are
> indeed doing an access(W_OK) on that file. But given the nature of
> access(), I was not expecting to trigger an AVC with the accompanying
> noise from setroubleshootd and friends. A return code indicating that
> we cannot write is fine and expected, but the warnings are not.
> 
> What is the proper way to deal with this? That process will not (and
> should not) write to that file, so allowing writes seems very wrong.
> And putting a noaudit rule also feels like papering over the issue.
> 
> (and getting rid of the access() call is non-trivial, so that's not
> really an option at this point)
> 

A rule like this should do it:

dontaudit cupsd_t usr_t:file audit_access;

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 648 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20140908/85fec7b1/attachment.bin