On Wed, Oct 14, 2009 at 5:42 PM, Joshua Roys joshua.roys@gtri.gatech.edu wrote:

On 10/14/2009 03:42 PM, Daniel J Walsh wrote:

...

On 10/14/2009 01:30 PM, Joshua Roys wrote:

...

avc:  denied  { recv } for  saddr=1.2.3.4 src=500 daddr=4.3.2.1 dest=500 netif=eth0 scontext=system_u:system_r:racoon_t:s0-s15:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s15:c0.c1023 tclass=peer

On IRC it was mentioned the tcontext=...:s15:... could be an issue...?

Did you run the AVC through audit2why?

It said: Policy constraint violation.

Looking at policy/mls, I see this: # the peer/packet recv op mlsconstrain { peer packet } { recv }        (( l1 dom l2 ) or         (( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or         ( t1 == mlsnetread ));

And here are our contexts: scontext=system_u:system_r:racoon_t:s0-s15:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s15:c0.c1023

According to: http://www.patrickmcdaniel.org/pubs/sacmat07.pdf the mlsconstrain above expands to:

subject = system_u:system_r:racoon_t:s0-s15:c0.c1023 object = system_u:object_r:unlabeled_t:s15-s15:c0.c1023 l1 dom l2 = opl(dom, getl(subject), getl(object))          = opl(dom, s0, s15)          = FALSE

mlsnetreadtoclr appears to only be granted via: policy/modules/kernel/mls.if: mls_socket_read_to_clearance which is not granted to racoon_t

and mlsnetread: policy/modules/kernel/mls.if: mls_socket_read_all_levels which is also not given to racoon_t.

mlsconstrain { peer packet } { recv }        (( FALSE ) or         (( FALSE ) and ( h1 dom l2 )) or         ( FALSE ));

So, does anyone have a pointer to why my traffic is coming in at s15? Or any other advice would be appreciated!

Thanks for your help so far,

-- Josh

-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list

What do your SA's look like (/etc/racoon/key.conf)?

We are trying to run an at job which echoes something on the terminal as below

at 14:53 at> echo "hello" > /dev/pts/1 at> ^D

When we run the above in the permissive mode we get hello on our term. However when we run in enforcing mode nothing seems to happen. We do not get any sealerts either.

Can someone let us know what is going on in the enforcing mode and what would be a way to check the status of the job?

Thanks Anamitra & Radha

Bruno Wolff III wrote:

On Tue, Oct 20, 2009 at 16:52:43 -0700, "Anamitra Dutta Majumdar (anmajumd)"anmajumd@cisco.com wrote:

...

We are trying to run an at job which echoes something on the terminal as below

at 14:53 at> echo "hello"> /dev/pts/1 at> ^D

When we run the above in the permissive mode we get hello on our term. However when we run in enforcing mode nothing seems to happen. We do not get any sealerts either.

Can someone let us know what is going on in the enforcing mode and what would be a way to check the status of the job?

There might be a don't audit on that rule.

-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list

yep, check to see if there's a mislabel use restorecon * then like above just use make enableaudit while compiling the policy to generate any avc's that are in the don't audit section.

Justin P. Mattock

On Fri, Oct 16, 2009 at 9:19 AM, Joshua Roys joshua.roys@gtri.gatech.edu wrote:

On 10/15/2009 09:27 AM, Xavier Toth wrote:

...

On Wed, Oct 14, 2009 at 5:42 PM, Joshua Roys joshua.roys@gtri.gatech.edu  wrote:

...

On 10/14/2009 03:42 PM, Daniel J Walsh wrote:

...

On 10/14/2009 01:30 PM, Joshua Roys wrote:

...

avc:  denied  { recv } for  saddr=1.2.3.4 src=500 daddr=4.3.2.1 dest=500 netif=eth0 scontext=system_u:system_r:racoon_t:s0-s15:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s15:c0.c1023 tclass=peer

Looking at policy/mls, I see this: # the peer/packet recv op mlsconstrain { peer packet } { recv }        (( l1 dom l2 ) or         (( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or         ( t1 == mlsnetread ));

mlsnetreadtoclr appears to only be granted via: policy/modules/kernel/mls.if: mls_socket_read_to_clearance which is not granted to racoon_t

Hello,

We have ipsec working again, using something like:

($local_t and $remote_t being the local and remote types)

mls_socket_read_to_clearance(racoon_t)

allow $local_t $remote_t:association polmatch; allow $remote_t $local_t:association polmatch;

allow $local_t $remote_t:peer recv;

Thanks for the tips,

Joshua Roys

Here is what we are using. Some of this is because we do a fair amount of dynamic config in the init scripts, some may be redundant with other fixes in refpol/F11 because it was originally developed in F9.

policy_module(hack_ipsec,1.0.9)

require { type initrc_t, ipsec_spd_t; attribute domain; } allow domain ipsec_spd_t:association { polmatch sendto recvfrom };

require { type setkey_t, initrc_tmp_t; }

# autoconfiguration needs this gen_require(`type ipsec_conf_file_t, ipsec_key_file_t;'); allow initrc_t ipsec_conf_file_t:dir { write remove_name add_name }; allow initrc_t ipsec_conf_file_t:file { rename write setattr relabelfrom relabelto create unlink }; allow initrc_t ipsec_key_file_t:file { write read rename };

# get setkey to talk to me in enforcing mode gen_require(`type setkey_t, initrc_devpts_t, initrc_tmp_t;'); allow setkey_t initrc_tmp_t:file { read getattr};

gen_require(`type udev_t, ipsec_conf_file_t;'); allow udev_t ipsec_conf_file_t:file ioctl; allow udev_t self:key_socket create;

# runtime gen_require(` type racoon_t, ipsec_spd_t, unlabeled_t; '); allow unlabeled_t ipsec_spd_t:association polmatch; allow unlabeled_t self:association sendto;

allow racoon_t unlabeled_t:udp_socket recvfrom; allow racoon_t unlabeled_t:association setcontext;

mls_socket_read_to_clearance(racoon_t) mls_socket_write_to_clearance(racoon_t)

corenet_out_generic_if(racoon_t); corenet_udp_send_generic_node(racoon_t);