Re: [SELinux] Wildcard for object classes?

Re: [SELinux] Wildcard for object classes?

[Russell Coker]

On Sat, 29 Jan 2011, Simon Brandmair <sbrandmair@gmx.net> wrote:
> I just started looking into SELinux. I am wondering if there is a way to
> have wildcards in avc rules like:
> auditallow source_t target_t : * * ;
> which audits all access from source_t to target_t.
> 
> Or do I have to add all classes objects to the rule like:
> auditallow source_t target_t : {appletalk_socket, association,
> blk_file ... } * ;

No, there isn't such a wildcard at this time (AFAIK).  It might be worth 
adding one so I've moved this discussion to the SE Linux upstream mailing list 
(please don't CC debian-security on future replies).

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [SELinux] Wildcard for object classes?

[Guido Trentalancia]

Hello Simon and Russel !

On Sun, 06/03/2011 at 10.32 +1100, Russell Coker wrote:
> On Sat, 29 Jan 2011, Simon Brandmair <sbrandmair@gmx.net> wrote:
> > I just started looking into SELinux. I am wondering if there is a way to
> > have wildcards in avc rules like:
> > auditallow source_t target_t : * * ;
> > which audits all access from source_t to target_t.
> > 
> > Or do I have to add all classes objects to the rule like:
> > auditallow source_t target_t : {appletalk_socket, association,
> > blk_file ... } * ;
> 
> No, there isn't such a wildcard at this time (AFAIK).  It might be worth 
> adding one so I've moved this discussion to the SE Linux upstream mailing list 
> (please don't CC debian-security on future replies).

But perhaps you can define a set:

define(`all_the_stuff_i_need', `{ appletalk_socket association
blk_file ... }')

and then make use of it:

auditallow source_t target_t:all_the_stuff_i_need *;

Please double-check (what I told you but also the use of commas in the
list). The reference policy mailing list might also be a useful source
of information in this specific case.

Hope it helps.

Regards,

Guido


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [SELinux] Wildcard for object classes?

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/06/2011 12:32 AM, Russell Coker wrote:
> On Sat, 29 Jan 2011, Simon Brandmair <sbrandmair@gmx.net> wrote:
>> I just started looking into SELinux. I am wondering if there is a way to
>> have wildcards in avc rules like:
>> auditallow source_t target_t : * * ;
>> which audits all access from source_t to target_t.
>>
>> Or do I have to add all classes objects to the rule like:
>> auditallow source_t target_t : {appletalk_socket, association,
>> blk_file ... } * ;
> 
> No, there isn't such a wildcard at this time (AFAIK).  It might be worth 
> adding one so I've moved this discussion to the SE Linux upstream mailing list 
> (please don't CC debian-security on future replies).
> 

Not possible and as far as i know neither is your second suggestion.
This is because not all permissions can be used with all object classes.

You would add a rule for each object class type (or set of object
classes that share the same permissions):

auditallow source target:notdevfile_class_set *;
auditallow source target:devfile_class_set *;
auditallow source target:socket_class_set *;
auditallow source target:file_class_set *;

etc, etc.

I am not sure if auditallow is the right way to do this. Maybe the audit
suite has better options for your requirements.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1z0rMACgkQMlxVo39jgT/t6gCg1T3AquC6RVeUpY2KEnQMdZT1
AowAoJgPYENYYXvTmRJVhtqSXpxKwFbv
=zUKb
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [SELinux] Wildcard for object classes?

[Dave Quigley]

On 3/6/2011 1:30 PM, Dominick Grift wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/06/2011 12:32 AM, Russell Coker wrote:
>> On Sat, 29 Jan 2011, Simon Brandmair<sbrandmair@gmx.net>  wrote:
>>> I just started looking into SELinux. I am wondering if there is a way to
>>> have wildcards in avc rules like:
>>> auditallow source_t target_t : * * ;
>>> which audits all access from source_t to target_t.
>>>
>>> Or do I have to add all classes objects to the rule like:
>>> auditallow source_t target_t : {appletalk_socket, association,
>>> blk_file ... } * ;
>> No, there isn't such a wildcard at this time (AFAIK).  It might be worth
>> adding one so I've moved this discussion to the SE Linux upstream mailing list
>> (please don't CC debian-security on future replies).
>>
> Not possible and as far as i know neither is your second suggestion.
> This is because not all permissions can be used with all object classes.
>
> You would add a rule for each object class type (or set of object
> classes that share the same permissions):
>
> auditallow source target:notdevfile_class_set *;
> auditallow source target:devfile_class_set *;
> auditallow source target:socket_class_set *;
> auditallow source target:file_class_set *;
>
> etc, etc.
>
> I am not sure if auditallow is the right way to do this. Maybe the audit
> suite has better options for your requirements.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.16 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk1z0rMACgkQMlxVo39jgT/t6gCg1T3AquC6RVeUpY2KEnQMdZT1
> AowAoJgPYENYYXvTmRJVhtqSXpxKwFbv
> =zUKb
> -----END PGP SIGNATURE-----
>
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
>
You could start with the policy made with mp (Make Dummy Policy) since 
that has rules for one type on all object classes to allow all 
permissions. Then from there you could turn that into an interface 
instead so it would expand to that entire rule set. The only downside is 
if a new object class is added you'll have to modify the new interface 
to include that one as well.

Dave

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.