NB Networking

From SELinux Wiki
Revision as of 14:01, 25 September 2015 by RichardHaines (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

SELinux Networking Support

SELinux supports the following types of network labeling:

Internal labeling - This is where network objects are labeled and managed internally within a single machine (i.e. their labels are not transmitted as part of the session with remote systems). There are two types supported: SECMARK and NetLabel. There was a service known as 'compat_net' controls, however that was removed in kernel 2.6.30.
Labeled Networking - This is where labels are passed to/from remote systems where they can be interpreted and a MAC policy enforced on each system. There are two types supported: Labeled IPSec and CIPSO (Commercial IP Security Option).

There are two policy capability options that can be set within policy using the policycap statement that affect networking configuration:

network_peer_controls - This is always enabled in the latest Reference Policy source. The Fallback Labeling diagram shows the differences between the policy capability being set to 0 and 1.
always_use_network - This capability would normally be set to false. If true SECMARK and NetLabel peer labeling are always enabled even if there are no SECMARK, NetLabel or Labeled IPsec rules configured. This forces checking of the packet class to protect the system should any rules fail to load or they get maliciously flushed. Requires kernel 3.13 minimum.

The policy capability settings are available in userspace via the SELinux filesystem as shown in the SELinux Filesystem section.

To support peer labeling and CIPSO the NetLabel tools need to be installed:

yum install netlabel_tools

To support Labeled IPSec the IPSec tools need to be installed:

yum install ipsec-tools

It is also possible to use an alternative Labeled IPSec service that was OpenSwan but is now distributed as LibreSwan:

yum install libreswan 

It is important to note that the kernel must be configured to support these services. The F-20 kernels are configured to handle all the above services.

The Linux networking package iproute has an SELinux aware socket statistics command ss(8) that will show the SELinux context of network processes (-Z or --context option) and network sockets (-z or --contexts option). Although note that the socket contexts are taken from the inode associated to the socket and not from the actual kernel socket structure (as currently there is no standard kernel/userspace interface to achieve this).

SECMARK

SECMARK makes use of the standard kernel NetFilter framework that underpins the GNU / Linux IP networking sub-system. NetFilter services automatically inspects all incoming and outgoing packets and can place controls on interfaces, IP addresses (nodes) and ports with the added advantage of connection tracking. The SECMARK security extensions allow security contexts to be added to packets (SECMARK) or sessions (CONNSECMARK).

The NetFilter framework inspects and tag packets with labels as defined within iptables(8) and then uses the security framework (e.g. SELinux) to enforce the policy rules. Therefore SECMARK services are not SELinux specific as other security modules using the LSM infrastructure could also implement the same services (e.g. SMACK).

While the implementation of iptables / NetFilter is beyond the scope of this Notebook, there are tutorials available[1]. The SECMARK Processing diagram shows the basic structure with the process working as follows:

  • A table called the 'security table' is used to define the parameters that identify and 'mark' packets that can then be tracked as the packet travels through the networking sub-system. These 'marks' are called SECMARK and CONNSECMARK.
  • A SECMARK is placed against a packet if it matches an entry in the security table applying a label that can then be used to enforce policy on the packet.
  • The CONNSECMARK 'marks' all packets within a session[2] with the appropriate label that can then be used to enforce policy.

An example iptables[3] 'security table' entry is as follows:

# Flush the security table first:
iptables -t security -F

#-------------- INPUT IP Stream --------------------#

# This INPUT rule sets all packets to msg_filter.default_packet: as it is executed first:
iptables -t security -A INPUT -i lo -p tcp -d 127.0.0.0/8 -j SECMARK --selctx system.user:object_r:msg_filter.default_packet:s0

# These rules will replace the above context with the internal or
# external gateway if port 9999 or 1111 is found in either the source or
# destination port of the packet:
iptables -t security -A INPUT -i lo -p tcp --dport 9999 -j SECMARK --selctx system.user:object_r:msg_filter.ext_gateway.packet:s0
iptables -t security -A INPUT -i lo -p tcp --sport 9999 -j SECMARK --selctx system.user:object_r:msg_filter.ext_gateway.packet:s0
#
# The internal gateway:
iptables -t security -A INPUT -i lo -p tcp --dport 1111 -j SECMARK --selctx system.user:object_r:msg_filter.int_gateway.packet:s0
iptables -t security -A INPUT -i lo -p tcp --sport 1111 -j SECMARK --selctx system.user:object_r:msg_filter.int_gateway.packet:s0

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

#-------------- OUTPUT IP Stream --------------------#

# This OUTPUT rule sets all packets to msg_filter.default_packet: as it is executed first:
iptables -t security -A OUTPUT -o lo -p tcp -d 127.0.0.0/8 -j SECMARK --selctx system.user:object_r:msg_filter.default_packet:s0

# These rules will replace the above context with the internal or
# external gateway if port 9999 or 1111 is found in either the source or
# destination port of the packet:
iptables -t security -A OUTPUT -o lo -p tcp --dport 9999 -j SECMARK --selctx system.user:object_r:msg_filter.ext_gateway.packet:s0
iptables -t security -A OUTPUT -o lo -p tcp --sport 9999 -j SECMARK --selctx system.user:object_r:msg_filter.ext_gateway.packet:s0
#
# The internal gateway:
iptables -t security -A OUTPUT -o lo -p tcp --dport 1111 -j SECMARK --selctx system.user:object_r:msg_filter.int_gateway.packet:s0
iptables -t security -A OUTPUT -o lo -p tcp --sport 1111 -j SECMARK --selctx system.user:object_r:msg_filter.int_gateway.packet:s0

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

An example policy that makes use of SECMARK services is described in the Notebook source tarball. There are also articles "Transitioning to Secmark and "New secmark-based network controls for SELinux" that explain the services.

NetLabel - Fallback Peer Labeling

Fallback labeling can optionally be implemented on a system if the Labeled IPSec or CIPSO is not being used (hence 'fallback labeling'). If either Labeled IPSec or CIPSO are being used, then these take priority. There is an article "Fallback Label Configuration Example" that explains their usage, the netlabelctl(8) man page is also a useful reference.

The example message filter has an optional module that makes use of fallback labels and can be found in the Notebook source tarball.

The network peer controls have been extended to support an additional object class of 'peer' that is enabled by default in the F-20 policy as the network_peer_controls in /sys/fs/selinux/policy_capabilities is set to '1'. The Fallback Labeling diagram shows the differences between the policy capability network_peer_controls being set to 0 and 1.

NetLabel - CIPSO

To allow security levels to be passed over a network between MLS systems[4], the CIPSO protocol is used. This is defined in the CIPSO Internet Draft document (this is an obsolete document, however the protocol is still in use). The protocol defines how security levels are encoded in the IP packet header.

Note that only the level component of the security context is passed over the network. The exception is in loopback mode as explained in "Full SELinux Labels Over Loopback with NetLabel and CIPSO" available at http://paulmoore.livejournal.com/7234.html.

The protocol is implemented by the NetLabel service (see netlabelctl(8)) and can be used by other security modules that use the LSM infrastructure. The NetLabel implementation supports:

  1. Tag Type 1 bit mapped format that allows a maximum of 256 sensitivity levels and 240 categories to be mapped.
  2. A non-translation option where labels are passed to / from systems unchanged (for host to host communications as show in the MLS Systems on the same network diagram).
  3. A translation option where both the sensitivity and category components can be mapped for systems that have either different definitions for labels or information can be exchanged over different networks (for example using an SELinux enabled gateway as a guard as shown in the MLS Systems on different networks communicating via a gateway diagram).

Labeled IPSec

Labeled IPSec has been built into the standard GNU / Linux IPSec services as described in the "Leveraging IPSec for Distributed Authorization. the IPSec communications diagram shows the basic components that form the service based on IPSec tools where it is generally used to set up either an encrypted tunnel between two machines[5] or an encrypted transport session. The extensions defined in describe how the security context is configured and negotiated between the two systems (called security associations (SAs) in IPSec terminology).

Basically what happens is as follows[6]:

  1. The security policy database (SPD) defines the security communications characteristics to be used between the two systems. This is populated using the setkey(8) utility with an example shown in the Configuration Example section.
  2. The SAs have their configuration parameters such as protocols used for securing packets, encryption algorithms and how long the keys are valid held in the Security Association database (SAD). For Labeled IPSec the security context (or labels) is also defined within the SAD. SAs can be negotiated between the two systems using either racoon or pluto[7] that will automatically populate the SAD or manually by the setkey utility (see the example below).
  3. Once the SAs have been negotiated and agreed, the link should be active.

A point to note is that SAs are one way only, therefore when two systems are communicating (using the above example), one system will have an SA, SAout for processing outbound packets and another SA, SAin, for processing the inbound packets. The other system will also create two SAs for processing its packets.

Each SA will share the same cryptographic parameters such as keys and protocol[8] (e.g. ESP (encapsulated security payload) and AH (authentication header)).

The object class used for the association of an SA is association and the permissions available are as follows:

polmatch Match the SPD context (-ctx) entry to an SELinux domain (that is contained in the SAD -ctx entry)
recvfrom Receive from an IPSec association.
sendto Send to an IPSec association.
setcontext Set the context of an IPSec association on creation (e.g. when running setkey the process will require this permission to set the context in the SAD and SPD, also racoon / pluto will need this permission to build the SAD).


When running Labeled IPSec it is recommended that the systems use the same type/version of policy to avoid any problems with them having different meanings.

There are worked examples of Labeled IPSec sessions showing manual configuration using setkey and IKE exchanges using racoon[9] and LibreSwan (pluto) configurations in the Notebook source tarball (note that the LibreSwan examples use the kernel netkey services).

There is a further example in the "Secure Networking with SELinux" article.

There is a good reference covering "Basic Labeled IPsec Configuration" available at:

http://www.redhat.com/archives/redhat-lspp/2006-November/msg00051.html


Configuration Examples

There are two possible labeled IPSec solutions available:

IPSec Tools - This uses the setkey(8) tools and racoon(8) Internet Key Exchange (IKE) daemon.
LibreSwan - This uses ipsec(8) tools and pluto(8) Internet Key Exchange (IKE) daemon.

Both work in much the same way but use different configuration files with samples shown below. The one point they have in common is that to start any session for label exchange using IKE, setkey must be used to initially set up the labels in the security policy database (SPD) on each machine.

Another point to note is that if interoperating between racoon and pluto the IPSEC Security Association Attribute values are different:

  • racoon has this hard-wired to a value of '10'.
  • pluto is configurable with a default of '32001'. To interoperate with racoon the ipsec.conf(5) file must have:
config setup
secctx_attr_value = 10

The following example configurations show the common setkey configuration to set up the SPD entries and then a sample supporting racoon and pluto (LibreSwan) configuration file:

Add label / context to SPD for loopback:

# setkey -f configuration file entries for RACOON SA configuration
#
# If the Internal Gateway module (int_gateway.conf) is not loaded,
# then the entries should be removed from this file.
#

# Flush the SAD and SPD
flush;
spdflush;

#
########### Security Policy Database entries ##########################
#

# Note that the only part of the security context matched against is
# the 'type' (e.g. ext_gateway_t).

# Security policies for external gateway:
spdadd 127.0.0.1 127.0.0.1 tcp
-ctx 1 1 "unconfined.user:msg_filter.role:msg_filter.ext_gateway.process:s0"
-P out ipsec esp/transport//require;

spdadd 127.0.0.1 127.0.0.1 tcp
-ctx 1 1 "unconfined.user:msg_filter.role:msg_filter.ext_gateway.process:s0"
-P in ipsec esp/transport//require;

# Security policies for internal gateway:
spdadd 127.0.0.1 127.0.0.1 tcp
-ctx 1 1 "unconfined.user:msg_filter.role:msg_filter.int_gateway.process:s0"
-P out ipsec esp/transport//require;

spdadd 127.0.0.1 127.0.0.1 tcp
-ctx 1 1 "unconfined.user:msg_filter.role:msg_filter.int_gateway.process:s0"
-P in ipsec esp/transport//require;

racoon configuration:

# Racoon IKE daemon configuration file.
# See 'man racoon.conf' for a description of the format and entries.

path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";
path script "/etc/racoon/scripts";

sainfo anonymous
{
lifetime time 1 hour ;
encryption_algorithm 3des, blowfish 448, rijndael ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}

LibreSwan / pluto loopback configuration:

# /etc/ipsec.conf - Libreswan IPsec configuration file

version 2.0
config setup
plutorestartoncrash=false
protostack=netkey
plutodebug="all"

# A "secctx_attr_value" is optional for >= 3.6 as defaults to this:
secctx_attr_value = 32001

conn labeled_loopback_test
auto=start
rekey=no
authby=secret
type=transport
left=127.0.0.1
right=127.0.0.1
ike=3des-sha1
phase2=esp
phase2alg=aes-sha1
loopback=yes
labeled_ipsec=yes
policy_label=unconfined.user:msg_filter.role:msg_filter.ext_gateway.process:s0
leftprotoport=tcp
rightprotoport=tcp


Previous
Home
Next



  1. There is a very good tutorial at http://www.frozentux.net/documents/iptables-tutorial/, however it does not cover the security table that was introduced by: http://lwn.net/Articles/267140/. It is still possible to use the 'mangle table' to hold security labels.
  2. For example, an ftp session where the server is listening on a specific port (the destination port) but the client will be assigned a random source port. The CONNSECMARK will ensure that all packets for the ftp session are marked with the same label.
  3. The tables will not load correctly if the policy does not allow the iptables domain to relabel the security table entries unless permissive mode is enabled (i.e. iptables must have the relabel permission for each entry in the table).
  4. Note only the security levels are passed over the network as the other components of the security context are not part of standard MLS systems (as it may be that the remote end is a Trusted Solaris system).
  5. Also known as a virtual private network (VPN).
  6. There is an “IPSec HOWTO" at http://www.ipsec-howto.org that gives the gory details, however it does not cover Labeled IPSec.
  7. These are the Internet Key Exchange (IKE) daemons that exchange encryption keys securely and also supports Labeled IPSec parameter exchanges.
  8. The GNU / Linux version supports a number of secure protocols, see setkey(8) for details.
  9. Unfortunately racoon core dumps when using non MCS/MLS policies.