racoon denials

[Dominick Grift]

On Mon, Aug 17, 2009 at 05:37:42PM +0200, Daniel Fazekas wrote:
> On Aug 17, 2009, at 16:10, Dominick Grift wrote:
>
>> echo "setkey_domtrans(racoon_t)" >> myracoon.te;
>
> This line results in the follow error:
> myracoon.te":6:ERROR 'syntax error' at token 'setkey_domtrans' on line  
> 3308:
> setkey_domtrans(racoon_t)

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;

make -f /usr/share/selinux/devel/Makefile myracoon.pp
sudo semodule -i myracoon.pp

assuming setkey_t is the domain type

>
> And the avcs which cause audit2allow to suggest this remains:
> allow racoon_t setkey_exec_t:file { read execute open execute_no_trans };
>
> But it seems to have cleared up all the rest, thanks!
>
>> This is just the rules translated into policy. I am not positive  
>> whether racoon or setkey creates the object in tmp, read shadow, and  
>> get attributes of fs_t:filesystem.
>
> racoon itself reads shadow.
> The rest is all caused by racoon executing a bash shell script, which in 
> turn executes setkey.
>
> I believe now that the tmp file accesses are likely caused by that  
> script's use of here-document << syntax to specify the input for setkey.
>
> eg.:
>
> /sbin/setkey -c << EOT
> spdadd ${INTERNAL_ADDR4}/32[any] 0.0.0.0/0[any] any -P in ipsec
>         esp/tunnel/${REMOTE}-${LOCAL}/require;
> spdadd 0.0.0.0/0[any] ${INTERNAL_ADDR4}/32[any] any -P out ipsec
>         esp/tunnel/${LOCAL}-${REMOTE}/require;
> EOT
>
> --
> 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/20090817/c6cc8591/attachment.sig>