* [refpolicy] MLS policy and networking @ 2012-02-28 22:07 David Shifflett 2012-03-05 19:06 ` David Shifflett 2012-03-08 18:30 ` Paul Moore 0 siblings, 2 replies; 8+ messages in thread From: David Shifflett @ 2012-02-28 22:07 UTC (permalink / raw) To: refpolicy 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 This yields: # cat /etc/selinux/mls/modules/active/ports.local portcon tcp 55055 system_u:object_r:user_t:s0 # cat /etc/selinux/mls/modules/active/interfaces.local netifcon eth1 system_u:object_r:user_t:s0 system_u:object_r:user_t:s0 netifcon eth2 system_u:object_r:user_t:s0 system_u:object_r:user_t:s0 # cat /etc/selinux/mls/modules/active/nodes.local nodecon ipv4 192.168.2.1 255.255.255.0 system_u:object_r:user_t:s0 nodecon ipv4 192.168.3.1 255.255.255.0 system_u:object_r:user_t:s0 # semanage port -l | grep 55055 user_t tcp 55055 # semanage node -l 192.168.2.1 255.255.255.0 ipv4 system_u:object_r:user_t:s0 192.168.3.1 255.255.255.0 ipv4 system_u:object_r:user_t:s0 # semanage interface -l eth1 system_u:object_r:user_t:s0 eth2 system_u:object_r:user_t:s0 I am running a simple python server program listening, accepting connections on port 55055, and reading/writing data from/to the client. The python program reports it's context via selinux.getcon() and works whether the context is user_u:user_r:user_t:s0-s15:c0.c1023 or user_u:user_r:user_t:s1-s15:c0.c1023 It appears that the MLS policy isn't being enforced, or I am missing something. I am new to SELinux so hopefully I am doing something simple wrong. Let me know if there is any other data I need to provide. Any help sorting this out would be appreciated, Thanks, David Shifflett ^ permalink raw reply [flat|nested] 8+ messages in thread
* [refpolicy] MLS policy and networking 2012-02-28 22:07 [refpolicy] MLS policy and networking David Shifflett @ 2012-03-05 19:06 ` David Shifflett 2012-03-06 13:27 ` Christopher J. PeBenito 2012-03-08 18:30 ` Paul Moore 1 sibling, 1 reply; 8+ messages in thread From: David Shifflett @ 2012-03-05 19:06 UTC (permalink / raw) To: refpolicy I have a little more information to add. I reversed the MLS levels of the node/interface/port and process. With the node/interface/port labeled at s1, the process running at s0 is NOT prevented from accessing the network. Please help me understand if I am configuring things incorrectly, or if the MLS policy isn't being correctly applied to network nodes/interfaces/ports. David Shifflett 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 > > This yields: > # cat /etc/selinux/mls/modules/active/ports.local > portcon tcp 55055 system_u:object_r:user_t:s0 > > # cat /etc/selinux/mls/modules/active/interfaces.local > netifcon eth1 system_u:object_r:user_t:s0 system_u:object_r:user_t:s0 > netifcon eth2 system_u:object_r:user_t:s0 system_u:object_r:user_t:s0 > > # cat /etc/selinux/mls/modules/active/nodes.local > nodecon ipv4 192.168.2.1 255.255.255.0 system_u:object_r:user_t:s0 > nodecon ipv4 192.168.3.1 255.255.255.0 system_u:object_r:user_t:s0 > > # semanage port -l | grep 55055 > user_t tcp 55055 > > # semanage node -l > 192.168.2.1 255.255.255.0 ipv4 system_u:object_r:user_t:s0 > 192.168.3.1 255.255.255.0 ipv4 system_u:object_r:user_t:s0 > > # semanage interface -l > eth1 system_u:object_r:user_t:s0 > eth2 system_u:object_r:user_t:s0 > > I am running a simple python server program listening, > accepting connections on port 55055, > and reading/writing data from/to the client. > > The python program reports it's context via selinux.getcon() > and works whether the context is > user_u:user_r:user_t:s0-s15:c0.c1023 > or > user_u:user_r:user_t:s1-s15:c0.c1023 > > It appears that the MLS policy isn't being enforced, > or I am missing something. > > I am new to SELinux so hopefully I am doing something simple wrong. > Let me know if there is any other data I need to provide. > > > Any help sorting this out would be appreciated, > Thanks, > David Shifflett > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy > ^ permalink raw reply [flat|nested] 8+ messages in thread
* [refpolicy] MLS policy and networking 2012-03-05 19:06 ` David Shifflett @ 2012-03-06 13:27 ` Christopher J. PeBenito 0 siblings, 0 replies; 8+ messages in thread From: Christopher J. PeBenito @ 2012-03-06 13:27 UTC (permalink / raw) To: refpolicy On 03/05/12 14:06, David Shifflett wrote: > I have a little more information to add. > > I reversed the MLS levels of the node/interface/port and process. > With the node/interface/port labeled at s1, the process running at s0 is > NOT prevented from accessing the network. > > Please help me understand if I am configuring things incorrectly, > or if the MLS policy isn't being correctly applied to network > nodes/interfaces/ports. > > David Shifflett > > > 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 >> >> This yields: >> # cat /etc/selinux/mls/modules/active/ports.local >> portcon tcp 55055 system_u:object_r:user_t:s0 >> >> # cat /etc/selinux/mls/modules/active/interfaces.local >> netifcon eth1 system_u:object_r:user_t:s0 system_u:object_r:user_t:s0 >> netifcon eth2 system_u:object_r:user_t:s0 system_u:object_r:user_t:s0 >> >> # cat /etc/selinux/mls/modules/active/nodes.local >> nodecon ipv4 192.168.2.1 255.255.255.0 system_u:object_r:user_t:s0 >> nodecon ipv4 192.168.3.1 255.255.255.0 system_u:object_r:user_t:s0 >> >> # semanage port -l | grep 55055 >> user_t tcp 55055 >> >> # semanage node -l >> 192.168.2.1 255.255.255.0 ipv4 system_u:object_r:user_t:s0 >> 192.168.3.1 255.255.255.0 ipv4 system_u:object_r:user_t:s0 >> >> # semanage interface -l >> eth1 system_u:object_r:user_t:s0 >> eth2 system_u:object_r:user_t:s0 >> >> I am running a simple python server program listening, >> accepting connections on port 55055, >> and reading/writing data from/to the client. >> >> The python program reports it's context via selinux.getcon() >> and works whether the context is >> user_u:user_r:user_t:s0-s15:c0.c1023 >> or >> user_u:user_r:user_t:s1-s15:c0.c1023 >> >> It appears that the MLS policy isn't being enforced, >> or I am missing something. >> >> I am new to SELinux so hopefully I am doing something simple wrong. >> Let me know if there is any other data I need to provide. I can't remember if F13 still had compat_net. Do you have a /selinux/compat_net, and if so is it 0 or 1? If it is 0 or nonexistant, then the above won't work, because you're using the new SELinux network access controls (SECMARK). If you have /selinux/compat_net, you could change it to 1 and then nodes, netifs, and ports will start working as you expect. If not, then you have to use iptables/SECMARK to do the labeling. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* [refpolicy] MLS policy and networking 2012-02-28 22:07 [refpolicy] MLS policy and networking David Shifflett 2012-03-05 19:06 ` David Shifflett @ 2012-03-08 18:30 ` Paul Moore 2012-03-08 19:19 ` David Shifflett 1 sibling, 1 reply; 8+ messages in thread From: Paul Moore @ 2012-03-08 18:30 UTC (permalink / raw) To: refpolicy 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". 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. -- paul moore www.paul-moore.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* [refpolicy] MLS policy and networking 2012-03-08 18:30 ` Paul Moore @ 2012-03-08 19:19 ` David Shifflett 2012-03-09 20:43 ` Paul Moore 0 siblings, 1 reply; 8+ messages in thread From: David Shifflett @ 2012-03-08 19:19 UTC (permalink / raw) To: refpolicy 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). That seems inconsistent with the fact that SECMARK can be used to label traffic based on port. Is the 'normal' way to use SECMARK for nodes and interfaces and 'semanage' for ports? 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. > ^ permalink raw reply [flat|nested] 8+ messages in thread
* [refpolicy] MLS policy and networking 2012-03-08 19:19 ` David Shifflett @ 2012-03-09 20:43 ` Paul Moore 2012-03-09 22:33 ` David Shifflett 0 siblings, 1 reply; 8+ messages in thread From: Paul Moore @ 2012-03-09 20:43 UTC (permalink / raw) To: refpolicy 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [refpolicy] MLS policy and networking 2012-03-09 20:43 ` Paul Moore @ 2012-03-09 22:33 ` David Shifflett 2012-03-12 13:30 ` Paul Moore 0 siblings, 1 reply; 8+ messages in thread From: David Shifflett @ 2012-03-09 22:33 UTC (permalink / raw) To: refpolicy Ok, given the below info, I'll re ask my original question. I don't care about labeling all the network traffic or packets. I want to label the interface and have the system enforce the policy based on the process label and the interface label. If I use semanage to label the eth1 interface s0 and the eth2 interface s1 Why is a process at s1 allowed to access eth1? I am not in 'compat_net' mode, so if semanage isn't that right way to label the interface, should I use SECMARK, or netlabelctl? BTW, I agree, clear as mud :) dave Paul Moore wrote: <snip> > * 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 :) > ^ permalink raw reply [flat|nested] 8+ messages in thread
* [refpolicy] MLS policy and networking 2012-03-09 22:33 ` David Shifflett @ 2012-03-12 13:30 ` Paul Moore 0 siblings, 0 replies; 8+ messages in thread From: Paul Moore @ 2012-03-12 13:30 UTC (permalink / raw) To: refpolicy On Friday, March 09, 2012 02:33:08 PM David Shifflett wrote: > Ok, given the below info, I'll re ask my original question. > > I don't care about labeling all the network traffic or packets. > I want to label the interface and have the system enforce the policy based > on the process label and the interface label. All of my original advice still applies. * http://paulmoore.livejournal.com/5536.html > If I use semanage to label the eth1 interface s0 and the eth2 interface s1 > > Why is a process at s1 allowed to access eth1? Short answer: because you've only half-way configured the labeled networking access controls. Longer answer: for both performance and policy reasons, the network access controls lie dormant/disabled until you fully configured them. Once they are fully configured then they will become active and you can start enforcing the access controls you describe above. When you only run the semanage commands as you've described above, you can't enforce the network access controls as the network traffic "loops back" into the system after being sent. > I am not in 'compat_net' mode, so if semanage isn't that right way to label > the interface, should I use SECMARK, or netlabelctl? You should be using the commands I sent you earlier. It may not be as simple as you want it to be, but it is the way it works. > BTW, I agree, clear as mud :) > > dave > > Paul Moore wrote: > <snip> > > > * 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 :) > > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy -- paul moore www.paul-moore.com ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-03-12 13:30 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-02-28 22:07 [refpolicy] MLS policy and networking David Shifflett 2012-03-05 19:06 ` David Shifflett 2012-03-06 13:27 ` Christopher J. PeBenito 2012-03-08 18:30 ` Paul Moore 2012-03-08 19:19 ` David Shifflett 2012-03-09 20:43 ` Paul Moore 2012-03-09 22:33 ` David Shifflett 2012-03-12 13:30 ` Paul Moore
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.