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
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
>
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
http://www.tresys.com | oss.tresys.com
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
http://www.paul-moore.com
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.
>
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
http://www.paul-moore.com
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 :)
>
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
http://www.paul-moore.com