All of lore.kernel.org
 help / color / mirror / Atom feed
From: dac.override@gmail.com (Dominick Grift)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] write AVC on access()?
Date: Wed, 10 Sep 2014 12:13:06 +0200	[thread overview]
Message-ID: <20140910101305.GA7776@x220.network2> (raw)
In-Reply-To: <20140910110559.59739bd6@ossman.lkpg.cendio.se>

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 

      reply	other threads:[~2014-09-10 10:13 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-08  7:23 [refpolicy] write AVC on access()? Pierre Ossman
2014-09-08 15:37 ` Dominick Grift
2014-09-10  9:05 ` Pierre Ossman
2014-09-10 10:13   ` Dominick Grift [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140910101305.GA7776@x220.network2 \
    --to=dac.override@gmail.com \
    --cc=refpolicy@oss.tresys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.