racoon denials

Dominick Grift domg472 at gmail.com
Tue Aug 18 09:17:51 UTC 2009

On Mon, Aug 17, 2009 at 10:46:16PM +0200, Daniel Fazekas wrote:
> On Aug 17, 2009, at 18:09, Dominick Grift wrote:
>> So that means there is no such shared policy. we can can work around  
>> that by adding the following to the myracoon.te:
>> echo "require { type setkey_exec_t, setkey_t; }" >> myracoon.te;
>> echo "domtrans_pattern(racoon_t, setkey_exec_t, setkey_t)" >>  
>> myracoon.te;
>> assuming setkey_t is the domain type
> That did compile, but now there's a whole new set of setkey_t denials.
> allow setkey_t racoon_t:key_socket { read write };
> allow setkey_t racoon_t:netlink_route_socket { read write };
> allow setkey_t racoon_t:udp_socket { read write };
> allow setkey_t racoon_t:unix_stream_socket { read write };
> allow setkey_t racoon_tmp_t:file { read getattr };

I was kind of expecting that.

The issue is that most of these rules look really ugly.

Maybe there is a 'good' reason why setkey_domtrans is not available.

Maybe we should not let racoon_t domain transition to setkey_t.

try this rule instead of the domtrans_pattern():

can_exec(racoon_t, setkey_exec_t)

(maybe theres a setkey_exec() available for you to call)

This will cause racoon_t to run setkey in the racoon_t domain instead.

> I now had to make setkey_t permissive. Previously it only required doing 
> that for racoon_t.
> --
> fedora-selinux-list mailing list
> fedora-selinux-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-selinux-list/attachments/20090818/e9146349/attachment.sig>

More information about the fedora-selinux-list mailing list