Home Learn Linux Linux Tutorials Using SELinux and iptables Together

Using SELinux and iptables Together

Wednesday, 16 March 2011 08:39 Daniel J. Walsh | Exclusive

22 retweet Like 8 likes. Sign Up to see what your friends like.

One of the things I have wanted to do with SELinux for years is figure out a way to make SELinux and
iptables work together, but each time I looked at it, my use cases became too complicated. James Morris
and Paul Moore worked on a tool called Secmark way back in the Red Hat Enterprise Linux (RHEL) 5 time
frame. My simple implementation of Secmark is to use iptables rules to define labels on packets as they
flow within an SELinux system.
Secmark has been used for years in Multi-level Security (MLS) type environments, but pretty much ignored
in targeted policy. On an MLS system, the security label of the packet is more important then the type label.
Meaning you can prevent a process running as “unclassified†from reading a “Top Secretâ€
packet.
Note: This article is not about labeled networking. (Labels Packets passing between machines over the
Network).
In a targeted system, we do not usually use levels, so I wanted to use type enforcement, meaning
controlling which processes can send/recv packets based on the type of the process and the type of the
packet. Secmark allows you to write rules that label packets that come into port 80 allowing you to write a
rule that allows a process labeled httpd_t to send/recv packets labeled httpd_packet_t. But what about
Firefox, Squid, etc.? My fear about labeling packets was an explosion of packets would generate very
complicated policy. Taking this to the extreme you might end up with packet types for every port type,
httpd_packet_t, bind_packet_t, dns_packet_t .... Or even worse, a type for each port_types and network
combined. httpd_internet_packet_t versus httpd_intranet_packet_t, or httpd_eth0_packet_t and
httpd_eth1_packet_t.
As you can see this would quickly become confusing. And writing policy would become impossible for the
distributions.
unlabeled_t packet type
Currently, by default, we do not label any packets in policy, so the kernel labels these packets as
unlabeled_t. Because of this every SELinux domain on the system that uses the network, has the rules:
allow MYDOMAIN unlabed_t:packet { send recv };
This means that if you used Secmark to labeled packets, and you take the fire wall down, the kernel would
start labeling all packets as unlabeled_t. Every network domain would suddenly gain more access. This
means taking down your firewall or reloading your firewall, you would not only allow ports to be attacked
from outside, you would lower your SELinux protection, potentially allowing confined domains to start to
send/recv packets from untrusted networks.
Removing the unlabeled_t rules
In the latest Fedora Releases I added a module called unlabelednet containing all the rules to allow
MYDOMAIN unlabeled_t:packet {send recv }. If you disable this policy package, all confined domains will
loose the ability to send/recv unlabeled_t packets. I will be back porting this to RHEL6. This means you
can stop confined domains from using the network unless you write rules for a labeled packet.
Use Case
As I mentioned above, every time I looked into this problem, I ended up with an explosion of types. I finally
came upon a couple of use cases where I could write some simple rules and policy to further secure my
laptop. I wanted to write policy to prevent all confined domains that are started at boot (system domains)
from talking to the external network, and allow all domains started by my login process (user domains) to
talk to both the internal and external networks. The idea here is I do not want processes like avahi, or
sssd, or sshd or any other process that gets started at boot to be listening or affected by packets from an
untrusted network. I want processes started by my login, like Firefox or my VPN to be able to talk to the
network. If my vpn is shut down the system domains are off the network, while I can still use the Internet
for browsing and email.
The nice thing about this example is you could use it to setup an Apache server that could only talk to the
internal network and would reject packets from the external network.
I decided to create just three types for my network. I will explain the SELinux policy later in the article.
type internal_packet_t: Iptables will label all packets that originate or are destined for the internal
network as internal_packet_t;
type dns_external_packet_t: Iptables will label all packets destined to the external network on udp/tcp
port 53 as dns_external_packet_t. I added this type because I wanted to dontaudit certain confined
domains from talking to dns servers external to my private network.
Type external_packet_t: Will be the default label for all packets on the machine not covered by the the
first two definitions.
Introducing secmarkgen
I am no iptables expert. Calling me an iptables novice would be kind. So I asked Eric Paris to write up an
example of how you could write iptables rules to apply a label to a packet. I took his rules and generated a
helper shell script called secmarkgen, you can either use my secmarkgen script to generate iptables
rules or generate them yourself.
Running secmarkgen -h will show you the usage:

Usage: ./secmarkgen -i

Usage: ./secmarkgen -s NAME

Usage: ./secmarkgen -T iptablescmd -P protocol -p port[:...] -N network[,...]

-t selinux_type -m MCS NAME

Usage: ./secmarkgen -f NAME

You need to write rules to initialize secmark labels.

./secmarkgen -i
Then you need to name your networks. (Iptables chain)
./secmarkgen -s INTERNAL
Now you can add one or more rules about this named network.
./secmarkgen -n 255.255.255.255,127/8,10.0.0.0/8,172.16.0.0/16,224/24,192.168/16
INTERNAL
Now you want to finish the secmark rules by assigning a packet type label to the network.
./secmarkgen -f -t internal_packet_t INTERNAL
Here's the script generated the following iptables rules:

###################################################################

# ./secmarkgen -i

###################################################################

iptables -F -t security

iptables -t security -A INPUT -m state --state ESTABLISHED,RELATED -j

CONNSECMARK --restore

iptables -t security -A OUTPUT -m state --state ESTABLISHED,RELATED -j

CONNSECMARK --restore

###################################################################

# ./secmarkgen -s INTERNAL

###################################################################

iptables -t security -X INTERNAL 2> /dev/null

iptables -t security -N INTERNAL

###################################################################

# ./secmarkgen -n
255.255.255.255,127/8,10.0.0.0/8,172.16.0.0/16,224/24,192.168/16 INTERNAL
 ###################################################################

iptables -A OUTPUT -t security -d

255.255.255.255,127/8,10.0.0.0/8,172.16.0.0/16,224/24,192.168/16 -j INTERNAL

iptables -A INPUT -t security -s

255.255.255.255,127/8,10.0.0.0/8,172.16.0.0/16,224/24,192.168/16 -j INTERNAL

###################################################################

# ./secmarkgen -f -t internal_packet_t INTERNAL

###################################################################

iptables -t security -A INTERNAL -j SECMARK --selctx

system_u:object_r:internal_packet_t:s0

iptables -t security -A INTERNAL -j CONNSECMARK --save

iptables -t security -A INTERNAL -j ACCEPT

I will leave it up to the reader to examine and understand the iptables rules. (I always loved that cop out
when I was in school.)
The secmark_test Script
Here is my full Secmark script (secmark_test.sh) that I use to generate the rules to confine my network:

./secmarkgen -i

./secmarkgen -s INTERNAL

./secmarkgen -n
255.255.255.255,127/8,10.0.0.0/8,172.16.0.0/16,224/24,192.168/16 INTERNAL

./secmarkgen -f -t internal_packet_t INTERNAL

./secmarkgen -s DNS

./secmarkgen -P udp -p 53 DNS

./secmarkgen -P tcp -p 53 DNS

./secmarkgen -f -t dns_external_packet_t DNS

./secmarkgen -s EXTERNAL

./secmarkgen EXTERNAL

./secmarkgen -f -t external_packet_t EXTERNAL

./secmarkgen -T ip6tables -i

./secmarkgen -T ip6tables -s INTERNAL

./secmarkgen -T ip6tables -n FEC0::/10,::1/128,FF::/8,FE80::/10,FC00::/7

INTERNAL

./secmarkgen -T ip6tables -f -t internal_packet_t INTERNAL

./secmarkgen -T ip6tables -s EXTERNAL

./secmarkgen -T ip6tables EXTERNAL

./secmarkgen -T ip6tables -f -t external_packet_t EXTERNAL

Now I generate the iptables rules:

# ./secmark_test.sh > /tmp/rules
One problem is I can not install the rules yet. Since I have not written the SELinux policy to define the
*_packet_t packet types, the iptables rules would fail to install. If you tried to install these rules you would
see a dmesg output saying the kernel does not know what an internal_packet_t type is.
SELinux Policy
Here is the policy that I use, called secmark.te :

policy_module(secmark, 1.0)

gen_require(`

attribute domain;

attribute sysadm_usertype;

# Domains that a staff user could transition to

attribute staff_usertype;

attribute telepathy_domain;

type ping_t;

type vpnc_t;

type ssh_t;

type nsplugin_t;

type mozilla_plugin_t;

# System domains that want to talk to the external network

type ntpd_t;

type sssd_t;

')

# Type Definitions

attribute external_packet;

type internal_packet_t;

corenet_packet(internal_packet_t)

type dns_external_packet_t, external_packet;

corenet_packet(dns_external_packet_t)

type external_packet_t, external_packet;

corenet_packet(external_packet_t)

# Allow Rules

allow domain internal_packet_t:packet { recv send };

allow sysadm_usertype external_packet:packet { recv send };

allow staff_usertype external_packet:packet { recv send };

allow vpnc_t external_packet:packet { recv send };

allow ssh_t external_packet:packet { recv send };

allow mozilla_plugin_t external_packet:packet { recv send };

allow nsplugin_t external_packet:packet { recv send };

allow telepathy_domain external_packet:packet { recv send };

allow ping_t external_packet:packet { recv send };

allow ntpd_t external_packet:packet { recv send };

dontaudit sssd_t dns_external_packet_t:packet { recv send };

Lets look at the policy more closely. First there's:
policy_module(secmark, 1.0)
This just defines the policy module. Next, we add requirements:

gen_require(`

attribute domain;

attribute sysadm_usertype;

# Domains that a staff user could transition to

attribute staff_usertype;

attribute telepathy_domain;

type ping_t;

type vpnc_t;

type ssh_t;

type nsplugin_t;

type mozilla_plugin_t;

# System domains that want to talk to the external network

type ntpd_t;

type sssd_t;

')

When you are writing SELinux policy you have to reference all types/attributes before using them in an
allow rule. You can either define new types or in this case add a gen_requires block. The gen_requires
block tells SELinux to not install this policy, if any of these attributes or types are not defined in other parts
of policy.
Acouple of attributes to look at, in selinux policy domain, is an attribute of all processes types.
staff_usertype is an attribute that is given to all specific staff user processes. Similarly sysadm_usertype
is an attribute given to all specific sysadm user processes, If you added other user types like xguest or
user, you would have to add similar rules in policy. The telepathy_domain is the domain of all the telepathy
applications.
In this section I define the new types that I will use for identifying network packets on my system. I also
defined an attribute external_packet, so I can group rules related to external packets together. I am using
the corenet_packet interface, to identify to SELinux that these types are associated with packets.

attribute external_packet;

type internal_packet_t;

corenet_packet(internal_packet_t)

type dns_external_packet_t, external_packet;

corenet_packet(dns_external_packet_t)

type external_packet_t, external_packet;

corenet_packet(external_packet_t)

Now lets look at the allow rules:

allow domain internal_packet_t:packet { recv send };
This rule allows all processes on the system to send and receive all internal packets.
The next rules allow all (most) staff and sysadm domains, programs executed by the staff or sysadm user
directly, to send and recv external packets. Notice I use the attribute external_packet instead of the types
directly. This gives the staff domains access to both the external_packet_t and the dns_external_packet_t.

allow sysadm_usertype external_packet:packet { recv send };

allow staff_usertype external_packet:packet { recv send };

allow vpnc_t external_packet:packet { recv send };

allow ssh_t external_packet:packet { recv send };

allow mozilla_plugin_t external_packet:packet { recv send };

allow nsplugin_t external_packet:packet { recv send };

allow telepathy_domain external_packet:packet { recv send };

allow ping_t external_packet:packet { recv send };

The next rule allows the ntpd_t domain to send and receive external packets, since ntpd talks to time
servers on the public network. I could have defined an ntp_external_packet_t, and added iptables rules to
make this more secure, but I decided not, since I did not want an explosion of types.
allow ntpd_t external_packet:packet { recv send };
dontaudit sssd_t dns_external_packet_t:packet { recv send };
The sssd program looks at all entries in my /etc/resolv.conf and checks to see if it can use them.
When I use vpn to come into my network, I end up with dns records from the external and internal network
in my /etc/resolv.conf file.
Since I do not want sssd talking to any system other then on my private network, I want to dontaudit this
access.
Compile, Install and Run
Now it's time to pull everything together. First I compile my policy:
# make -f /usr/share/selinux/devel/Makefile
Then I install my policy:
# semodule -i secmark.pp
Now I can install the rules on my system:

# sh /tmp/rules
I want to tell iptables and ip6tables to remember for the next boot.

# service iptables save

iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ]
# service ip6tables save
ip6tables: Saving firewall rules to /etc/sysconfig/ip6table[ OK ]

At this point every packet on my machine should have one of the three labels.
Now I can watch for avc messages concerning any of these labeled packets. If I see ones I can decide
whether or not I want to allow/dontaudit these avc messages, or try to figure out if something is going very
wrong on my system.

Daniel J. Walsh

Daniel Walsh has worked in the computer security field for over 25 years. Dan joined Red Hat in August
2001. He has led the SELinux project, concentrating on the application space and policy development.
Previously, Dan worked on Netect/Bindview on HackerShield and BVControl for Unix, Vulnerability
Assessment Products. Prior to this Dan worked for Digital Equipment Corporation on the Athena Project
along with designing and developing the AltaVista Firewall and AltaVista Tunnel (VPN) Products. Dan
has a BAin Mathematics from the College of the Holy Cross and a MS in Computer Science from
Worcester Polytechnic Institute.