Difference between revisions of "NB Networking"

From SELinux Wiki
Jump to: navigation, search
Line 1: Line 1:
 
= SELinux Networking Support =
 
= SELinux Networking Support =
 
SELinux supports the following types of network labeling:
 
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).
  
'''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 three types supported: those known as "compat_net" controls that label nodes, interfaces and ports; SECMARK that labels packets; and fallback peer labeling.
+
There are two policy capability options that can be set within policy using the <tt>policycap</tt> statement that affect networking configuration:
 +
: '''network_peer_controls''' - This is always enabled in the latest Reference Policy source. The [http://taiga.selinuxproject.org/~rhaines/NB4-diagrams/14-fallback.png 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 <tt>packet</tt> class to protect the system should any rules fail to load or they get maliciously flushed. Requires kernel 3.13 minimum.
  
'''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. This is also known as "peer labeling". There are two types supported: Labeled IPSec and CIPSO (commercial IP security option).
+
The policy capability settings are available in userspace via the SELinux filesystem as shown in the [[NB_LSM#SELinux Filesystem | SELinux Filesystem]] section.
  
Note that F-12 does not have NetLabel or IPSec tools installed as standard, therefore yum can be used to install them as shown below:
+
To support peer labeling and CIPSO the NetLabel tools need to be installed:
 
<pre>
 
<pre>
 
yum install netlabel_tools
 
yum install netlabel_tools
 +
</pre>
  
 +
To support Labeled IPSec the IPSec tools need to be installed:
 +
<pre>
 
yum install ipsec-tools
 
yum install ipsec-tools
 
</pre>
 
</pre>
  
== compat_net Controls ==
+
It is also possible to use an alternative Labeled IPSec service that was OpenSwan but is now distributed as LibreSwan:
These labeling services make use of the [[NetworkStatements | Network Labeling Statements]] to label network object nodes, interfaces and ports with a security context that are then used to enforce controls. The [[NetworkStatements | Network Labeling Statements]] section defines each of the statements with examples of their usage.
+
<pre>
 +
yum install libreswan
 +
</pre>
  
The [http://taiga.selinuxproject.org/~rhaines/diagrams/14-compat_net.png compat_net Controls] diagram shows how these network statements are used and the type of allow rules that would be required.
+
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.
  
In a future release of the Linux kernel these controls will be removed and replaced by the SECMARK services with the Reference Policy also being updated.
+
The Linux networking package <tt>iproute</tt> has an SELinux aware socket statistics command <tt>'''ss'''(8)</tt> that will show the SELinux context of network processes (<tt>-Z</tt> or <tt>--context</tt> option) and network sockets (<tt>-z</tt> or <tt>--contexts</tt> 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 ==
SECMARK makes use of standard the kernel NetFilter framework that underpins the GNU / Linux IP networking sub-system. NetFilter 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 and CONNSECMARK are security extensions to the Netfilter iptables that allow security contexts to be added to packets (SECMARK) or sessions (CONNSECMARK) such as those used by ftp (as some applications within a single session can use a number of different ports, some fixed and others dynamically allocated).
+
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 is used to inspect and tag packets with labels as defined within the iptables and then use the security framework (e.g. SELinux) to enforce the policy rules. Therefore SECMARK services are not SELinux specific as other security modules that use the LSM infrastructure could also implement the same services (e.g. SMACK).
+
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<ref name="ftn19">There is a very good tutorial at [http://iptables-tutorial.frozentux.net/iptables-tutorial.html http://iptables-tutorial.frozentux.net/iptables-tutorial.html].</ref>. The [http://taiga.selinuxproject.org/~rhaines/diagrams/15-secmark.png SECMARK Processing] diagram shows the basic structure and the process works as follows:
+
While the implementation of iptables / NetFilter is beyond the scope of this Notebook, there are tutorials available<ref name="ftn16"><sup>There is a very good tutorial at [http://www.frozentux.net/documents/iptables-tutorial/ http://www.frozentux.net/documents/iptables-tutorial/], however it does not cover the security table that was introduced by: [http://lwn.net/Articles/267140/ http://lwn.net/Articles/267140/]. It is still possible to use the 'mangle table' to hold security labels.</sup></ref>. The [http://taiga.selinuxproject.org/~rhaines/NB4-diagrams/13-secmark.png 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<ref name="ftn17"><sup>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.</sup></ref> with the appropriate label that can then be used to enforce policy.
  
* A table called the "mangle table" is used to define the parameters that identify and "mark" packets that can then tracked as the packet travels through the networking sub-system. These "marks" are called SECMARK and CONNSECMARK.
+
An example iptables<ref name="ftn18"><sup>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).</sup></ref> 'security table' entry is as follows:
* A SECMARK is placed against a packet if it matches an entry in the mangle table. This marker is used to apply a security context (a label) that can then enforce policy on the packet.
+
* The CONNSECMARK "marks" all packets within a session<ref name="ftn20">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.</ref> with the appropriate label that can then be used to enforce policy.
+
 
+
An example iptables<ref name="ftn21">Note that the iptables will not load correctly if the policy does not allow the iptables domain to relabel the SECMARK labels (unless permissive mode is enabled).</ref> entry is as follows:
+
 
<pre>
 
<pre>
# Flush the mangle table first:
+
# Flush the security table first:
iptables -t mangle -F
+
iptables -t security -F
  
#----------------------------------- INPUT IP Stream ---------------------------------------------#
+
#-------------- INPUT IP Stream --------------------#
# This INPUT rule sets all packets to default_secmark_packet_t
+
iptables -t mangle -A INPUT -i lo -p tcp -d 127.0.0.0/8 -j SECMARK --selctx system_u:object_r:default_secmark_packet_t
+
  
#------------------------------------ OUTPUT IP Stream -------------------------------------------#
+
# This INPUT rule sets all packets to msg_filter.default_packet: as it is executed first:
# This OUTPUT rule sets all packets to default_secmark_packet_t
+
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
iptables -t mangle -A OUTPUT -o lo -p tcp -d 127.0.0.0/8 -j SECMARK --selctx system_u:object_r:default_secmark_packet_t
+
</pre>
+
  
An example loadable module that makes use of SECMARK services is described in the Building the SECMARK Test Loadable Module section of volume 2, there is also an article "[http://james-morris.livejournal.com/11010.html New secmark-based network controls for SELinux]" that explains the services.
+
# 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
  
As stated in the compat_net Controls section above, SECMARK will be replacing these and there is an article "[http://paulmoore.livejournal.com/4281.html Transitioning to Secmark]" that explains the transition.
+
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
 +
</pre>
 +
 
 +
An example policy that makes use of SECMARK services is described in the Notebook source tarball. There are also articles "[http://paulmoore.livejournal.com/4281.html Transitioning to Secmark] and "[http://james-morris.livejournal.com/11010.html New secmark-based network controls for SELinux]" that explain the services.
  
 
== NetLabel - Fallback Peer Labeling ==
 
== 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 "[http://paulmoore.livejournal.com/1758.html Fallback Label Configuration Example]" that explains the usage.
+
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 "[http://paulmoore.livejournal.com/1758.html Fallback Label Configuration Example]" that explains their usage, the <tt>'''netlabelctl'''(8)</tt> man page is also a useful reference.
  
The example message filter has an optional module that makes use of fallback labels as explained in the Overview of modules section of volume 2.  
+
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 has been extended to support an additional object class of "peer", although by default this is not enabled in F-12. To enabled this functionality the policy capability needs to be set as explained in the NetLabel Module Support for network_peer_controls section of the Sample Policy Source volume 2 where an example loadable module is given. The [http://taiga.selinuxproject.org/~rhaines/diagrams/16-fallback.png Fallback Labeling] diagram shows the differences between the policy capability <tt>network_peer_controls</tt> set to 0 and 1.
+
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 <tt>/sys/fs/selinux/policy_capabilities</tt> is set to '<tt>1</tt>'. The [http://taiga.selinuxproject.org/~rhaines/NB4-diagrams/14-fallback.png 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<ref name="ftn19"><sup>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).</sup></ref>, the CIPSO protocol is used. This is defined in the [http://tools.ietf.org/html/draft-ietf-cipso-ipsecurity-01 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.
  
== Labeled IPSec ==
+
Note that only the level component of the security context is passed over the network. The exception is in loopback mode as explained in "[http://paulmoore.livejournal.com/7234.html Full SELinux Labels Over Loopback with NetLabel and CIPSO]" available at [http://paulmoore.livejournal.com/7234.html http://paulmoore.livejournal.com/7234.html].
Labeled IPSec has been built into the standard GNU / Linux IPSec services as described in the "[http://nsrc.cse.psu.edu/tech_report/NAS-TR-0037-2006.pdf Leveraging IPSec for Distributed Authorization]" document. The [http://taiga.selinuxproject.org/~rhaines/diagrams/17-ipsec.png IPSec communications] diagram shows the basic components that form the IPSec service where it is generally used to set up either an encrypted tunnel between two machines<ref name="ftn22">Also known as a virtual private network (VPN).</ref> or an encrypted transport session. The extensions defined in the "[http://nsrc.cse.psu.edu/tech_report/NAS-TR-0037-2006.pdf Leveraging IPSec for Distributed Authorization]" document describe how the security context is used and negotiated between the two systems (called security associations (SAs) in IPSec terminology).
+
  
Basically what happens is as follows<ref name="ftn23">There is an "IPSec HOWTO" at [http://www.ipsec-howto.org/ http://www.ipsec-howto.org] that gives the gory details, however it does not cover Labeled IPSec.</ref>:
+
The protocol is implemented by the NetLabel service (see <tt>'''netlabelctl'''(8)</tt>) 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 [http://taiga.selinuxproject.org/~rhaines/NB4-diagrams/15-mls1.png 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 [http://taiga.selinuxproject.org/~rhaines/NB4-diagrams/16-mls2.png MLS Systems on different networks communicating via a gateway] diagram).
  
# 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 and an example is shown below.
+
== Labeled IPSec ==
# 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(8)<ref name="ftn24">This is the Internet Key Exchange (IKE) daemon that exchanges encryption keys securely and also supports Labeled IPSec parameter exchanges.</ref> that will automatically populate the SAD or manually by the setkey utility (see the example below).
+
Labeled IPSec has been built into the standard GNU / Linux IPSec services as described in the "[http://nsrc.cse.psu.edu/tech_report/NAS-TR-0037-2006.pdf Leveraging IPSec for Distributed Authorization]. the [http://taiga.selinuxproject.org/~rhaines/NB4-diagrams/17-ipsec.png 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<ref name="ftn20"><sup>Also known as a virtual private network (VPN).</sup></ref> 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<ref name="ftn21"><sup>There is an “IPSec HOWTO" at [http://www.ipsec-howto.org/ http://www.ipsec-howto.org] that gives the gory details, however it does not cover Labeled IPSec.</sup></ref>:
 +
# 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 | 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<ref name="ftn22"><sup>These are the Internet Key Exchange (IKE) daemons that exchange encryption keys securely and also supports Labeled IPSec parameter exchanges.</sup></ref> 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.
 
# 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 if two systems are communicating then (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.  
+
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<ref name="ftn25">The GNU / Linux version supports a number of secure protocols, see the setkey man page for details.</ref> such as AH (authentication header) and ESP (encapsulated security payload).  
+
Each SA will share the same cryptographic parameters such as keys and protocol<ref name="ftn23"><sup>The GNU / Linux version supports a number of secure protocols, see '''setkey'''(8) for details.</sup></ref> (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:
 
The object class used for the association of an SA is association and the permissions available are as follows:
  
 
{| border="1"
 
{| border="1"
| <tt>polmatch</tt>
+
| polmatch
 
| Match the SPD context (-ctx) entry to an SELinux domain (that is contained in the SAD -ctx entry)
 
| Match the SPD context (-ctx) entry to an SELinux domain (that is contained in the SAD -ctx entry)
  
 
|-
 
|-
| <tt>recvfrom</tt>
+
| recvfrom
 
| Receive from an IPSec association.
 
| Receive from an IPSec association.
  
 
|-
 
|-
| <tt>sendto</tt>
+
| sendto
 
| Send to an IPSec association.
 
| Send to an IPSec association.
  
 
|-
 
|-
 
| setcontext
 
| 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 will need this permission to build the SAD).
+
| 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 / <tt>pluto</tt> will need this permission to build the SAD).
  
 
|}
 
|}
  
  
A worked example of a Labeled IPSec session showing manual and racoon<ref name="ftn26">Unfortunately racoon core dumps using the example base module decribed in volume 2 but does work using the standard Red Hat targeted policy.</ref> to configure the SAD is described in the Labeled IPSec Module Example section of the Sample Policy Source volume.
+
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 <tt>setkey</tt> and IKE exchanges using racoon<ref name="ftn24"><sup>Unfortunately racoon core dumps when using non MCS/MLS policies.</sup></ref> and LibreSwan (<tt>pluto</tt>) configurations in the Notebook source tarball (note that the LibreSwan examples use the kernel <tt>netkey</tt> services).
  
 
There is a further example in the "[http://securityblog.org/brindle/2007/05/28/secure-networking-with-selinux/ Secure Networking with SELinux]" article.
 
There is a further example in the "[http://securityblog.org/brindle/2007/05/28/secure-networking-with-selinux/ 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 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 <tt>'''setkey'''(8)</tt> tools and <tt>'''racoon'''(8)</tt> Internet Key Exchange (IKE) daemon.
 +
: LibreSwan - This uses <tt>'''ipsec'''(8)</tt> tools and <tt>'''pluto'''(8)</tt> 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, <tt>setkey</tt> 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:
 +
 +
* <tt>racoon</tt> has this hard-wired to a value of '<tt>10</tt>'.
 +
* <tt>pluto</tt> is configurable with a default of '<tt>32001</tt>'. To interoperate with <tt>racoon</tt> the <tt>'''ipsec.conf'''(5)</tt> file must have:
 
<pre>
 
<pre>
# setkey -f configuration file entries
+
config setup
 +
secctx_attr_value = 10
 +
</pre>
 +
 
 +
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:
 +
<pre>
 +
# 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 the SAD and SPD
 
flush;
 
flush;
 
spdflush;
 
spdflush;
  
# Security Association Database entries.
+
#
# 1) There would be another SAD entry on the other system (the client), where the IP addresses would be reversed.
+
########### Security Policy Database entries ##########################
# 2) The security context must be that of the running application.
+
#
  
add 172.16.96.30 172.16.96.31 esp 0x201
+
# Note that the only part of the security context matched against is
-ctx 1 1 "user_u:message_filter_r:ext_gateway_t"
+
# the 'type' (e.g. ext_gateway_t).
-E 3des-cbc 0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831;
+
  
# Security Policy Database entries.
+
# Security policies for external gateway:
# 1) there would be another SPD entry on the other system (the client), where the IP addresses would be reversed.
+
spdadd 127.0.0.1 127.0.0.1 tcp
# 2) The security context must be valid (i.e. defined in the active policy as it will be used by the polmatch permission
+
-ctx 1 1 "unconfined.user:msg_filter.role:msg_filter.ext_gateway.process:s0"
#    process to find a matching domain. (note only the "type" field is used unlike the SAD, where the context is the active process).
+
-P out ipsec esp/transport//require;
  
# SAin
+
spdadd 127.0.0.1 127.0.0.1 tcp
spdadd 172.16.96.30 172.16.96.31 any
+
-ctx 1 1 "unconfined.user:msg_filter.role:msg_filter.ext_gateway.process:s0"
-ctx 1 1 "system_u:object_r:ext_gateway_t"
+
 
-P in ipsec esp/transport//require;
 
-P in ipsec esp/transport//require;
# SAout
+
 
spdadd 172.16.96.31 172.16.96.30 any
+
# Security policies for internal gateway:
-ctx 1 1 "system_u:object_r:ext_gateway_t"
+
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;
 
-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;
 
</pre>
 
</pre>
  
To manually load the above configuration file to populate the SPD and SAD<ref name="ftn27">If using racoon, the SAs would be negotiated using information from the SPD on each machine, with the SAD then being populated by racoon calling the setkey services.</ref> the following command would be used:
+
racoon configuration:
 
<pre>
 
<pre>
setkey -f <SPD_configuration_file>
+
# 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 ;
 +
}
 
</pre>
 
</pre>
  
== NetLabel - CIPSO ==
+
LibreSwan / pluto loopback configuration:
To allow security levels to be passed over a network between MLS systems<ref name="ftn28">Note only the security levels are passed over as the SELinux security context is not part of a standard MLS system (as SELinux supports two MAC services (Type Enforcement and MLS)).</ref>, the CIPSO protocol is used that is defined in the [http://tools.ietf.org/html/draft-ietf-cipso-ipsecurity-01 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.
+
<pre>
 +
# /etc/ipsec.conf - Libreswan IPsec configuration file
  
The protocol is implemented by the NetLabel service and can be used by other security modules that use the LSM infrastructure. The NetLabel implementation supports:
+
version 2.0
 +
config setup
 +
plutorestartoncrash=false
 +
protostack=netkey
 +
plutodebug="all"
  
# Tag Type 1 bit mapped format that allows a maximum of 256 sensitivity levels and 240 categories to be mapped.
+
# A "secctx_attr_value" is optional for >= 3.6 as defaults to this:
# A non-translation option where labels are passed to / from systems unchanged (for host to host communications as show in the [http://taiga.selinuxproject.org/~rhaines/diagrams/18-mls1.png MLS Systems on the same network] diagram).
+
secctx_attr_value = 32001
# 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 [http://taiga.selinuxproject.org/~rhaines/diagrams/19-mls2.png MLS Systems on different networks communicating via a gateway] diagram).
+
  
 +
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
 +
</pre>
 +
 +
 +
{| style="width: 100%;" border="0"
 +
|-
 +
| [[NB_Userspace_Libraries | '''Previous''']]
 +
| <center>[[NewUsers | '''Home''']]</center>
 +
| <center>[[NB_VM | '''Next''']]</center>
 +
|}
  
  

Revision as of 15:06, 7 December 2014

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.