All of lore.kernel.org
 help / color / mirror / Atom feed
From: pcclark@nps.edu (Paul Clark)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] MLS ping?
Date: Wed, 4 Apr 2012 11:07:09 -0700	[thread overview]
Message-ID: <4F7C8DCD.8090606@nps.edu> (raw)
In-Reply-To: <4F74CB4F.8040305@nps.edu>

It turns out that the reason why an SELinux system cannot respond to a 
ping when the MLS policy is enabled, is that the kernel thread that 
responds to the echo request is apparently labeled at system high, and 
therefore cannot do an MLS write-down to lower-level interfaces.  [I 
wonder if ARPs would also fail?]

I got around the ping problem by modifying the mls policy file.  I added
     ( t1 == kernel_t ) or
as the next-to-last line in the mlsconstrain statement that starts as
     mlsconstrain { netif } { egress }

I don't know what the side-effects of this might be.

-Paul

On 3/29/12 1:51 PM, Paul Clark wrote:
> With a modified MLS policy (described below):
> I can connect from SELinux (Fedora 13) to other systems.
> But, I cannot ping from other systems to SELinux.
>
> Configuring two interfaces with different MLS labels, I can ping from 
> SELinux to other non-SELinux systems on both interfaces, but I cannot 
> ping to SELinux on either interface. I can ssh to SELinux on the 
> interface labeled s0. (I understand the failure of ssh through the 
> interface labeled s1 because sshd is at s0.  Of course, that may not 
> be why it is failing).
>
> I have two interfaces configured as follows:
>
> Using semanage:
> eth0 = system_u:object_r:netif_t:s0
> eth1 = system_u:object_r:netif_t:s1
>
> Using netlabelctl:
> interface eth0
>   address:0.0.0.0/0
>   label: "system_u:object_r:netlabel_peer_t:s0"
> interface eth1
>   address:0.0.0.0/0
>   label: "system_u:object_r:netlabel_peer_t:s1"
>
> I modifed the MLS policy as follows:
>   allow kernel_t netif_t : netif egress;
>   corenet_inout_generic_if(netlabel_peer_t)
>   corenet_inout_generic_node(netlabel_peer_t)
>   allow ping_t netlabel_peer_t : peer recv;
>
> The following audit record would indicate that when responding to a 
> ping request received on eth1, the kernel is operating at system high 
> and therefore cannot write down to eth1.  But that doesn't explain why 
> I can ping on eth0 at s0.
> type=AVC msg=audit(13330453265.336:92_: avc: denied {egress} for 
> saddr=192.168.0.13 daddr=192.168.0.14 netif=eth1 
> scontext=system_u:system_r:kernel_t:s15:c0.c1023 
> tcontext=system_u:object_r:netif_t:s1 tclass=netif
>
> Any thoughts?
>
> -Paul
>
> .
>

      reply	other threads:[~2012-04-04 18:07 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-29 20:51 [refpolicy] MLS ping? Paul Clark
2012-04-04 18:07 ` Paul Clark [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F7C8DCD.8090606@nps.edu \
    --to=pcclark@nps.edu \
    --cc=refpolicy@oss.tresys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.