strange avc with racoon under f-11 mls

Daniel J Walsh dwalsh at redhat.com
Wed Oct 14 19:42:28 UTC 2009


On 10/14/2009 01:30 PM, Joshua Roys wrote:
> Hello all,
> 
> I am trying to get ipsec/racoon running under f11 mls.  However, an
> annoying avc is preventing that.
> 
> 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...?
> 
> Here's a bit of the selinux-policy that I thought should be allowing this:
> ./policy/modules/system/ipsec.te:
> corenet_all_recvfrom_unlabeled(racoon_t)
> corenet_tcp_sendrecv_all_if(racoon_t)
> corenet_udp_sendrecv_all_if(racoon_t)
> corenet_tcp_sendrecv_all_nodes(racoon_t)
> corenet_udp_sendrecv_all_nodes(racoon_t)
> corenet_tcp_bind_all_nodes(racoon_t)
> corenet_udp_bind_all_nodes(racoon_t)
> corenet_udp_bind_isakmp_port(racoon_t)
> corenet_udp_bind_ipsecnat_port(racoon_t)
> 
> ./policy/modules/kernel/corenetwork.if.in:
> interface(`corenet_all_recvfrom_unlabeled',`
>         kernel_tcp_recvfrom_unlabeled($1)
>         kernel_udp_recvfrom_unlabeled($1)
>         kernel_raw_recvfrom_unlabeled($1)
>         kernel_recvfrom_unlabeled_peer($1)
> 
>         # XXX - at some point the oubound/send access check will be removed
>         # but for right now we need to keep this in place so as not to
> break
>         # older systems
>         kernel_sendrecv_unlabeled_association($1)
> ')
> 
> ./policy/modules/kernel/kernel.if:
> interface(`kernel_recvfrom_unlabeled_peer',`
>         gen_require(`
>                 type unlabeled_t;
>         ')
> 
>         allow $1 unlabeled_t:peer recv;
> ')
> 
> 
> 
> I'm not entirely certain if the following ipsec rules were necessary,
> but I added them anyway:
> *mangle
> :PREROUTING ACCEPT [0:0]
> :INPUT ACCEPT [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> :POSTROUTING ACCEPT [0:0]
> :selinux_input - [0:0]
> :selinux_output - [0:0]
> :selinux_new_input - [0:0]
> :selinux_new_output - [0:0]
> -A INPUT -j selinux_input
> -A OUTPUT -j selinux_output
> -A selinux_input -m state --state NEW -j selinux_new_input
> -A selinux_input -m state --state RELATED,ESTABLISHED -j CONNSECMARK
> --restore
> -A selinux_output -m state --state NEW -j selinux_new_output
> -A selinux_output -m state --state RELATED,ESTABLISHED -j CONNSECMARK
> --restore
> 
> -A selinux_new_input -j SECMARK --selctx
> system_u:object_r:server_packet_t:s0
> -A selinux_new_output -j SECMARK --selctx
> system_u:object_r:client_packet_t:s0
> 
> -A selinux_new_input -p udp --dport 500 -j SECMARK --selctx
> system_u:object_r:isakmp_server_packet_t:s0
> -A selinux_new_output -p udp --dport 500 -j SECMARK --selctx
> system_u:object_r:isakmp_client_packet_t:s0
> 
> -A selinux_new_input -j CONNSECMARK --save
> -A selinux_new_input -j RETURN
> -A selinux_new_output -j CONNSECMARK --save
> -A selinux_new_output -j RETURN
> COMMIT
> 
> Thanks in advance,
> 
> Joshua Roys
> 
> -- 
> fedora-selinux-list mailing list
> fedora-selinux-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> 
> 
Did you run the AVC through audit2why?




More information about the fedora-selinux-list mailing list