[refpolicy] write AVC on access()?

[refpolicy] write AVC on access()?

[Pierre Ossman]

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)

Rgds
-- 
Pierre Ossman           Software Development
Cendio AB		http://cendio.com
Teknikringen 8		http://twitter.com/ThinLinc
583 30 Link?ping	http://facebook.com/ThinLinc
Phone: +46-13-214600	http://plus.google.com/+CendioThinLinc

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20140908/f0e10908/attachment.bin 

[refpolicy] write AVC on access()?

[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 

[refpolicy] write AVC on access()?

[Pierre Ossman]

Dominick Grift wrote:

> A rule like this should do it:
> 
> dontaudit cupsd_t usr_t:file audit_access;

Thanks. That seems to be the correct approach for systems modern enough
to have audit_access. But I want to support older versions as well, and
figured that I'd be able to do so with an 'optional' section. Yet this:

> optional_policy(`
> 	gen_require(`
> 		type cupsd_t;
> 		class file { audit_access };
> 	')
> 
> 	dontaudit cupsd_t etc_t:file audit_access;
> ')

Still results in:

> libsepol.permission_copy_callback: Module thinlinc depends on permission audit_access in class file, not satisfied (No such file or directory).

And if I leave it out of the require section:

> optional_policy(`
>         gen_require(`
>                 type cupsd_t;
>         ')
>         dontaudit cupsd_t etc_t:file audit_access;
> ')

I get this:

> thinlinc.te":167:ERROR 'permission audit_access is not defined for class file' at token ';' on line 38285:
> #line 167
> 	dontaudit cupsd_t etc_t:file audit_access;

So I utterly fail to understand what 'optional' actually does. Is
missing types the only thing it can check for?

Rgds
-- 
Pierre Ossman           Software Development
Cendio AB		http://cendio.com
Teknikringen 8		http://twitter.com/ThinLinc
583 30 Link?ping	http://facebook.com/ThinLinc
Phone: +46-13-214600	http://plus.google.com/+CendioThinLinc

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20140910/6cc6beaa/attachment.bin 

[refpolicy] write AVC on access()?

[Dominick Grift]

On Wed, Sep 10, 2014 at 11:05:59AM +0200, Pierre Ossman wrote:
> Dominick Grift wrote:
> 
> > A rule like this should do it:
> > 
> > dontaudit cupsd_t usr_t:file audit_access;
> 
> Thanks. That seems to be the correct approach for systems modern enough
> to have audit_access. But I want to support older versions as well, and
> figured that I'd be able to do so with an 'optional' section. Yet this:
> 
> > optional_policy(`
> > 	gen_require(`
> > 		type cupsd_t;
> > 		class file { audit_access };
> > 	')
> > 
> > 	dontaudit cupsd_t etc_t:file audit_access;
> > ')
> 
> Still results in:
> 
> > libsepol.permission_copy_callback: Module thinlinc depends on permission audit_access in class file, not satisfied (No such file or directory).
> 
> And if I leave it out of the require section:
> 
> > optional_policy(`
> >         gen_require(`
> >                 type cupsd_t;
> >         ')
> >         dontaudit cupsd_t etc_t:file audit_access;
> > ')
> 
> I get this:
> 
> > thinlinc.te":167:ERROR 'permission audit_access is not defined for class file' at token ';' on line 38285:
> > #line 167
> > 	dontaudit cupsd_t etc_t:file audit_access;
> 
> So I utterly fail to understand what 'optional' actually does. Is
> missing types the only thing it can check for?
> 

Yes right, it is about missing custmizable identifiers rather than missing security attributes

If you want to play it safe then you could consider:

dontaudit cupsd_t usr_t:file write;

I suppose that should also get rid of that event, although it would probably be a bit more prone to error

Another option might be to just add support for the audit_access av permission in your policy (access_vectors) even though it might
not be supported n the kernel

Ofcourse that would not really solve much since you will still end up with events on systems using a kernel that does not support audit_access

-- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
http://subkeys.pgp.net:11371/pks/lookup?search=0x02DFF788&op=index
Dominick Grift
-------------- 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/20140910/d3bdc977/attachment.bin