From: paul@paul-moore.com (Paul Moore) Date: Fri, 09 Mar 2012 15:43:13 -0500 Subject: [refpolicy] MLS policy and networking In-Reply-To: <4F590648.5010305@nps.edu> References: <4F4D5038.3090001@nps.edu> <1513158.4FbGMoRZ6H@sifl> <4F590648.5010305@nps.edu> Message-ID: <4257537.7ZZEJ7UAa5@sifl> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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