strange avc with racoon under f-11 mls
|
View:
New views
10 Messages
—
Rating Filter:
Alert me
|
 |
strange avc with racoon under f-11 mls
by Joshua Roys-2
::
Rate this Message:
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@... https://www.redhat.com/mailman/listinfo/fedora-selinux-list |
|
|
Re: strange avc with racoon under f-11 mls
by Daniel J Walsh
::
Rate this Message:
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@... > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- fedora-selinux-list mailing list fedora-selinux-list@... https://www.redhat.com/mailman/listinfo/fedora-selinux-list |
|
|
Re: strange avc with racoon under f-11 mls
by Joshua Roys-2
::
Rate this Message:
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@... https://www.redhat.com/mailman/listinfo/fedora-selinux-list |
|
|
Re: strange avc with racoon under f-11 mls
by txtoth
::
Rate this Message:
On Wed, Oct 14, 2009 at 5:42 PM, Joshua Roys
<joshua.roys@...> 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@... > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > What do your SA's look like (/etc/racoon/key.conf)? -- fedora-selinux-list mailing list fedora-selinux-list@... https://www.redhat.com/mailman/listinfo/fedora-selinux-list |
|
|
Re: strange avc with racoon under f-11 mls
by Joshua Roys-2
::
Rate this Message:
On 10/15/2009 09:27 AM, Xavier Toth wrote:
> On Wed, Oct 14, 2009 at 5:42 PM, Joshua Roys > <joshua.roys@...> 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 -- fedora-selinux-list mailing list fedora-selinux-list@... https://www.redhat.com/mailman/listinfo/fedora-selinux-list |
|
|
No avcs generated after running at jobs in enforcing mode
by Anamitra Dutta Majumdar (anmajumd)
::
Rate this Message:
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 -- fedora-selinux-list mailing list fedora-selinux-list@... https://www.redhat.com/mailman/listinfo/fedora-selinux-list |
|
|
Re: No avcs generated after running at jobs in enforcing mode
by Bruno Wolff III
::
Rate this Message:
On Tue, Oct 20, 2009 at 16:52:43 -0700,
"Anamitra Dutta Majumdar (anmajumd)" <anmajumd@...> 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@... https://www.redhat.com/mailman/listinfo/fedora-selinux-list |
|
|
Re: No avcs generated after running at jobs in enforcing mode
by Justin P. Mattock
::
Rate this Message:
Bruno Wolff III wrote:
> On Tue, Oct 20, 2009 at 16:52:43 -0700, > "Anamitra Dutta Majumdar (anmajumd)"<anmajumd@...> 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@... > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > 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 -- fedora-selinux-list mailing list fedora-selinux-list@... https://www.redhat.com/mailman/listinfo/fedora-selinux-list |
|
|
Re: No avcs generated after running at jobs in enforcing mode
by Daniel J Walsh
::
Rate this Message:
On 10/20/2009 07:52 PM, Anamitra Dutta Majumdar (anmajumd) 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? > > Thanks > Anamitra & Radha > > -- > fedora-selinux-list mailing list > fedora-selinux-list@... > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > semodule -DB Run your test look for avc messages in /var/log/audit/audit.log pertaining to cron and terminals You need to add those rules using audit2allow. -- fedora-selinux-list mailing list fedora-selinux-list@... https://www.redhat.com/mailman/listinfo/fedora-selinux-list |
|
|
Re: strange avc with racoon under f-11 mls
by Joe Nall
::
Rate this Message:
On Fri, Oct 16, 2009 at 9:19 AM, Joshua Roys
<joshua.roys@...> wrote: > On 10/15/2009 09:27 AM, Xavier Toth wrote: >> >> On Wed, Oct 14, 2009 at 5:42 PM, Joshua Roys >> <joshua.roys@...> 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); -- fedora-selinux-list mailing list fedora-selinux-list@... https://www.redhat.com/mailman/listinfo/fedora-selinux-list |
| Free embeddable forum powered by Nabble | Forum Help |
