I need help understanding if SELinux supports restricting a confined application from binding to specific network interfaces. I cannot seem to make this work under F11 and F12 (using targeted, mls, and reference policies), or under RHEL 5.3U3 targeted.
Details: - I have a system with two network interfaces: eth0 and eth1. - I have an application that must only be allowed to read data from eth0 (raw and tcp). - I do not need to label packets.
Here's what I have tried 1) In a new policy module, I create new types: myApp_exec_t, myApp_t, myApp_eth0_t, myApp_eth1_t. 2) I use semanage -fcontext to label my application's executable file as myApp_exec_t 3) I assign eth0 with a new type: 'semanage interface -a -t myApp_eth0_t eth0' 4) I assign eth1 with a new type: 'semanage interface -a -t myApp_eth1_t eth1' 5) In my policy module, I allow the following: "allow myApp_t self:capability net raw", and "allow myApp_t self:tcp_socket { accept read }" 6) I verify that when I execute my application, using ps -efZ it is running in the myApp_t domain (has transitioned properly from unconfined_t)
The problem is, my app can read raw or tcp data from either eth0 or eth1 even though both interfaces have been assigned different types using semanage -interface.
Is this because 'allow myApp_t self:capability net_raw' does not distinguish between network interfaces? Is my understanding of semanage -interface incorrect - shouldn't labeling the interface result in no ability to use the interface unless explicitly allowed?
On 01/14/2010 03:08 PM, Jason Shaw wrote:
I need help understanding if SELinux supports restricting a confined application from binding to specific network interfaces. I cannot seem to make this work under F11 and F12 (using targeted, mls, and reference policies), or under RHEL 5.3U3 targeted.
Details:
- I have a system with two network interfaces: eth0 and eth1.
- I have an application that must only be allowed to read data from eth0
(raw and tcp).
- I do not need to label packets.
Here's what I have tried
- In a new policy module, I create new types: myApp_exec_t, myApp_t,
myApp_eth0_t, myApp_eth1_t. 2) I use semanage -fcontext to label my application's executable file as myApp_exec_t 3) I assign eth0 with a new type: 'semanage interface -a -t myApp_eth0_t eth0' 4) I assign eth1 with a new type: 'semanage interface -a -t myApp_eth1_t eth1' 5) In my policy module, I allow the following: "allow myApp_t self:capability net raw", and "allow myApp_t self:tcp_socket { accept read }" 6) I verify that when I execute my application, using ps -efZ it is running in the myApp_t domain (has transitioned properly from unconfined_t)
The problem is, my app can read raw or tcp data from either eth0 or eth1 even though both interfaces have been assigned different types using semanage -interface.
Is this because 'allow myApp_t self:capability net_raw' does not distinguish between network interfaces? Is my understanding of semanage -interface incorrect - shouldn't labeling the interface result in no ability to use the interface unless explicitly allowed?
This is how you can , i think, declare a netif type:
[dgrift@localhost Desktop]$ cat mynetif.te policy_module(mynetif, 1.0.0)
require { attribute netif_type; } type netif_test_t, netif_type;
You will need to label the netif manually though. unless you add it to corenetwork.te.in , with a context specification
[dgrift@localhost Desktop]$ sudo semanage interface -a -t netif_test_t -r s0-s0:c0.c1023 eth0 [dgrift@localhost Desktop]$ sudo semanage interface -l SELinux Interface Context
eth0 system_u:object_r:netif_test_t:s0-s0:c0.c1023
I assume this should also work for raw as there are interfaces suggesting it:
# Summary: Receive raw IP packets on generic interfaces. # Parameter domain #The type of the process performing this action. interface(`corenet_raw_receive_generic_if',` gen_require(` type netif_t; ')
allow $1 netif_t:netif { rawip_recv ingress }; ')
selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On Thu, 2010-01-14 at 07:08 -0700, Jason Shaw wrote:
I need help understanding if SELinux supports restricting a confined application from binding to specific network interfaces. I cannot seem to make this work under F11 and F12 (using targeted, mls, and reference policies), or under RHEL 5.3U3 targeted.
Details:
- I have a system with two network interfaces: eth0 and eth1.
- I have an application that must only be allowed to read data from
eth0 (raw and tcp).
- I do not need to label packets.
Here's what I have tried
- In a new policy module, I create new types: myApp_exec_t, myApp_t,
myApp_eth0_t, myApp_eth1_t. 2) I use semanage -fcontext to label my application's executable file as myApp_exec_t 3) I assign eth0 with a new type: 'semanage interface -a -t myApp_eth0_t eth0' 4) I assign eth1 with a new type: 'semanage interface -a -t myApp_eth1_t eth1' 5) In my policy module, I allow the following: "allow myApp_t self:capability net raw", and "allow myApp_t self:tcp_socket { accept read }" 6) I verify that when I execute my application, using ps -efZ it is running in the myApp_t domain (has transitioned properly from unconfined_t)
The problem is, my app can read raw or tcp data from either eth0 or eth1 even though both interfaces have been assigned different types using semanage -interface.
Is this because 'allow myApp_t self:capability net_raw' does not distinguish between network interfaces? Is my understanding of semanage -interface incorrect - shouldn't labeling the interface result in no ability to use the interface unless explicitly allowed?
The legacy network permission checks were removed in Linux 2.6.30, and even prior to that they had been disabled for a long time by default unless you set /selinux/compat_net to 1. These days you need to use secmark or the newer ingress/egress permission checks to achieve the same effect. Using secmark requires you to configure iptables SECMARK targets to label the packets. Using ingress/egress requires you to configure labeled networking (netlabel or labeled ipsec) and make sure that /selinux/policy_capabilities/network_peer_controls exists and is set to 1 (requires Linux >= 2.6.25 and a policy built with that capability). See: http://paulmoore.livejournal.com/4281.html http://paulmoore.livejournal.com/2128.html
selinux@lists.fedoraproject.org
-
Dominick Grift -
Jason Shaw -
Stephen Smalley