[refpolicy] MLS policy and networking

[paul@paul-moore.com (Paul Moore)]

On Thursday, March 08, 2012 11:19:36 AM David Shifflett wrote:
> Thanks for the responses.
> 
> Indeed the system is not in 'compat_net' mode.
> It is Fedora 13, 2.6.33
> 
> It sure would be nice if 'semanage' output a warning
> when not in 'compat_net' mode and the admin
> makes node and interface changes.
> 
> This brings up a slight confusion,
> even though I am not in 'compat_net' mode
> the 'semanage port ...' seems to work (take effect).

The network interface and port labels are used both in the compat_net world 
and in the modern world.

> That seems inconsistent with the fact that
> SECMARK can be used to label traffic based on port.

Unfortunately, the SELinux network access controls remain one of the darker 
corners of SELinux when documentation is concerned and as a result they are 
often misunderstood.

What you wanted to do, or rather what I understand you wanted to do, was to 
assign a security label to a network and restrict access to the network to 
those processes/domains which had the same MLS attributes, e.g. only ...:sX 
domains allowed to communicated over ...:sX networks.  In my opinion, this is 
best accomplished not with the secmark tools, but rather through the peer 
label based ingress/egress tools (the instructions contained in my previous 
email).

> Is the 'normal' way to use SECMARK for nodes and interfaces and 'semanage'
> for ports?

Perhaps some correction in terminology/understanding is in order:

* Secmark, or secmark labels, is a way of labeling network traffic based on 
the network attributes of the traffic (IP header information, etc.).

* Network peer labels, provided either by labeled IPsec or NetLabel, is a way 
of labeling network traffic based on the security attributes of the sender; in 
other words, the network peer label represents the security label of the 
process which sent the traffic.

* The semanage tools is simply a tool which assigns labels to resources and 
entities on the system.  In the case of network related "things" it can assign 
labels to interfaces and proto/port combinations.  It is important to note 
that semanage does not label network traffic.

Hopefully that makes it all as clear as mud :)

> Or do I have to use semanage and SECMARK in combination?
> 
> I'll read your suggested references,
> and hopefully be able to figure it out.
> 
> David Shifflett
> 
> Paul Moore wrote:
> > On Tuesday, February 28, 2012 02:07:52 PM David Shifflett wrote:
> >> I am trying to use the MLS policy to control access to various
> >> networks.
> >> 
> >> I am running on Fedora 13,
> >> # sestatus
> >> reports - enabled, mode enforcing, policy version 24, policy file mls
> >> 
> >> My system has eth1 192.168.2.1, and eth2 192.168.3.1.
> >> 
> >> I am trying to set the contexts correctly so that processes
> >> with a sensitivity of s0 can use eth1,
> >> and a sensitivity of s1 can use eth2
> >> 
> >> Nothing I have tried prevents a process at s1 from accessing
> >> a node/interface/port with a sensitivity of s0.
> >> 
> >> Here is what I have tried:
> >> (set everything to s0)
> >> semanage interface -a -r s0 -t user_t eth1
> >> semanage interface -a -r s0 -t user_t eth2
> >> semanage node -a -r s0 -t user_t -M 255.255.255.0 -p ipv4 192.168.2.1
> >> semanage node -a -r s0 -t user_t -M 255.255.255.0 -p ipv4 192.168.3.1
> >> semanage port -a -r s0 -t user_t -p tcp 55055
> > 
> > ...
> > 
> >> # semanage interface -l
> >> eth1 system_u:object_r:user_t:s0
> >> eth2 system_u:object_r:user_t:s0
> > 
> > Sorry for such a late response, but I would suggest the following changes:
> > 
> > 1. If you want only "s1" labeled traffic on eth2, you should probably
> > label it as such, e.g. "semanage interface -a -r s1 ... eth2".
> 
> Yes, I eventually planned to do it this way.
> But I wanted to ensure I was configuring things correctly,
> so I set it to 's0' expecting an 'access denied' error.
> 
> > 2. I would avoid using existing non-netif type names for your network
> > interfaces, e.g. "semanage interface -a -t my_netif_t ethX".  While
> > technically I don't think there is anything wrong (I may be wrong here)
> > with using "user_t", it will probably help you to keep things straight if
> > you use a type that is netif related.
> > 
> >> It appears that the MLS policy isn't being enforced, or I am missing
> >> something.
> > 
> > You're missing a few more steps, but first, as Chris has already
> > mentioned,
> > check that you are not operating in the *dreaded* (feel free to add
> > appropriate emphasis) "compat_net" mode.  See Chris' response to see how
> > to
> > check this on your system.
> > 
> > Assuming you are not in compat_net mode, you want to follow the
> > instructions> 
> > outlined on the page below (using your values of course):
> >  * http://paulmoore.livejournal.com/5536.html
> > 
> > The basic idea is that you need to do the following things to start
> > enforcing SELinux network policy on modern kernels:
> > 
> > 1. Set the network interface labels to match the security attributes of
> > their network. (You've pretty much done this already, see my earlier
> > comments)
> > 
> > 2. Configure some form of labeling for incoming network traffic; if you
> > aren't using either CIPSO or labeled IPsec - and odds are very good that
> > you are not - you should configure a static label for incoming network
> > traffic on each of your interfaces.  For example, a basic configuration
> > that would match your eth1/s0 and eth2/s1 requirement would look like
> > this (only IPv4 addresses> 
> > shown in this example):
> >  # netlabelctl unlbl add interface:eth1 address:0.0.0.0/0 \
> >  
> >                          label:system_u:object_r:netlabel_peer_t:s0
> >  
> >  # netlabelctl unlbl add interface:eth2 address:0.0.0.0/0 \
> >  
> >                          label:system_u:object_r:netlabel_peer_t:s1
> > 
> > 3. Write a policy module to match your desired network access control
> > requirements and you are all set.
> 
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
-- 
paul moore
www.paul-moore.com