strange avc with racoon under f-11 mls

[Joshua Roys]

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

[Daniel J Walsh]

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(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>  
>   
Did you run the AVC through audit2why?

[Joshua Roys]

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

[Ted Toth]

On Wed, Oct 14, 2009 at 5:42 PM, Joshua Roys
<joshua.roys(a)gtri.gatech.edu&gt; 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(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>  
What do your SA's look like (/etc/racoon/key.conf)?

[Joshua Roys]

On 10/15/2009 09:27 AM, Xavier Toth wrote:
>  On Wed, Oct 14, 2009 at 5:42 PM, Joshua Roys
>  <joshua.roys(a)gtri.gatech.edu&gt;  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

No avcs generated after running at jobs in enforcing mode

[Anamitra Dutta Majumdar]

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

No avcs generated after running at jobs in enforcing mode

[Bruno Wolff III]

On Tue, Oct 20, 2009 at 16:52:43 -0700,
  "Anamitra Dutta Majumdar (anmajumd)" <anmajumd(a)cisco.com&gt; 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.

No avcs generated after running at jobs in enforcing mode

[Justin P. Mattock]

Bruno Wolff III wrote:
>  On Tue, Oct 20, 2009 at 16:52:43 -0700,
>     "Anamitra Dutta Majumdar (anmajumd)"<anmajumd(a)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(a)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

No avcs generated after running at jobs in enforcing mode

[Daniel J Walsh]

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(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>  
>   
Might be something dontaudited. You need to turn off audit rules temporarily

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.

[Joe Nall]

On Fri, Oct 16, 2009 at 9:19 AM, Joshua Roys
<joshua.roys(a)gtri.gatech.edu&gt; wrote:
>  On 10/15/2009 09:27 AM, Xavier Toth wrote:
> >
> > On Wed, Oct 14, 2009 at 5:42 PM, Joshua Roys
> > <joshua.roys(a)gtri.gatech.edu&gt;  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);