Jaxelson at 20:47, 13 September 2010

2010-09-13T20:47:25Z

←Older revision		Revision as of 20:47, 13 September 2010
Line 142:		Line 142:
	----		----
	<references/>		<references/>
		+
		+	[[Category:Notebook]]

RichardHaines at 14:22, 18 May 2010

2010-05-18T14:22:43Z

←Older revision		Revision as of 14:22, 18 May 2010
Line 91:		Line 91:


-	A worked example of a Labeled IPSec session showing manual and racoon<ref name="ftn26"~~><sup~~>Unfortunately racoon core dumps using the example base module decribed in volume 2 but does work using the standard Red Hat targeted policy.~~</sup>~~</ref> to configure the SAD is described in the Labeled IPSec Module Example section of the Sample Policy Source volume.	+	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.

	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.
Line 124:		Line 124:
	</pre>		</pre>

-	To manually load the above configuration file to populate the SPD and SAD<ref name="ftn27"~~><sup~~>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.~~</sup>~~</ref> the following command would be used:	+	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:
	<pre>		<pre>
	setkey -f <SPD_configuration_file>		setkey -f <SPD_configuration_file>

RichardHaines: New page: = SELinux Networking Support = SELinux supports the following types of network labeling: '''Internal labeling''' - This is where network objects are labeled and managed internally within ...

2010-05-18T14:19:40Z

New page: = SELinux Networking Support = SELinux supports the following types of network labeling: '''Internal labeling''' - This is where network objects are labeled and managed internally within ...

New page

= 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 three types supported: those known as "compat_net" controls that label nodes, interfaces and ports; SECMARK that labels packets; and fallback peer labeling.

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

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:
<pre>
yum install netlabel_tools

yum install ipsec-tools
</pre>

== compat_net Controls ==
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.

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.

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.

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

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

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:

* 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.
* 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>
# Flush the mangle table first:
iptables -t mangle -F

#----------------------------------- 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 OUTPUT rule sets all packets to default_secmark_packet_t
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.

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.

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

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

== Labeled IPSec ==
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 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.
# 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).
# 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.

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

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

{| border="1"
| <tt>polmatch</tt>
| Match the SPD context (-ctx) entry to an SELinux domain (that is contained in the SAD -ctx entry)

|-
| <tt>recvfrom</tt>
| Receive from an IPSec association.

|-
| <tt>sendto</tt>
| 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 will need this permission to build the SAD).

|}

A worked example of a Labeled IPSec session showing manual and racoon<ref name="ftn26"><sup>Unfortunately racoon core dumps using the example base module decribed in volume 2 but does work using the standard Red Hat targeted policy.</sup></ref> to configure the SAD is described in the Labeled IPSec Module Example section of the Sample Policy Source volume.

There is a further example in the "[http://securityblog.org/brindle/2007/05/28/secure-networking-with-selinux/ Secure Networking with SELinux]" article.
<pre>
# setkey -f configuration file entries
#
# Flush the SAD and SPD
flush;
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.
# 2) The security context must be that of the running application.

add 172.16.96.30 172.16.96.31 esp 0x201
-ctx 1 1 "user_u:message_filter_r:ext_gateway_t"
-E 3des-cbc 0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831;

# Security Policy Database entries.
# 1) there would be another SPD entry on the other system (the client), where the IP addresses would be reversed.
# 2) The security context must be valid (i.e. defined in the active policy as it will be used by the polmatch permission
# process to find a matching domain. (note only the "type" field is used unlike the SAD, where the context is the active process).

# SAin
spdadd 172.16.96.30 172.16.96.31 any
-ctx 1 1 "system_u:object_r:ext_gateway_t"
-P in ipsec esp/transport//require;
# SAout
spdadd 172.16.96.31 172.16.96.30 any
-ctx 1 1 "system_u:object_r:ext_gateway_t"
-P out ipsec esp/transport//require;
</pre>

To manually load the above configuration file to populate the SPD and SAD<ref name="ftn27"><sup>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.</sup></ref> the following command would be used:
<pre>
setkey -f <SPD_configuration_file>
</pre>

== NetLabel - CIPSO ==
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.

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:

# 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/diagrams/18-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/diagrams/19-mls2.png MLS Systems on different networks communicating via a gateway] diagram).

----
<references/>

NB Networking - Revision history

Jaxelson at 20:47, 13 September 2010

RichardHaines at 14:22, 18 May 2010

RichardHaines: New page: = SELinux Networking Support = SELinux supports the following types of network labeling: '''Internal labeling''' - This is where network objects are labeled and managed internally within ...