Contents

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.

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.

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:

Tag Type 1 bit mapped format that allows a maximum of 256 sensitivity levels and 240 categories to be mapped.

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).

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).

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.

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).

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).

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:

↑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.

↑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).

↑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).