Information Security

SECMARK Without SELinux

Yes... it is possible

This is not common knowledge. Contrary to most literature, you can use SECMARK and CONNSECMARK without SELinux. This article explains what that means and provides evidence supporting my statement.

First, as of the 2.6.18 Linux kernel, the security table is available in iptables whether your distro has SELinux incorporated or not. Likewise, SECMARK and CONNSECMARK are both supported in the security table. The key is SELinux is able to identify "marks" set by SECMARK and CONNSECMARK via netfilter, and act upon them to inspect and react to network traffic in ways that extend netfilter's packet filtering and inspection capabilities.

SECMARK and CONNSECMARK were introduced into the Linux kernel in the mid-2000's, at a time when various Linux gurus sought to take better advantage of netfilter's capabilities. James Morris - the architect of SECMARK - wrote a blog post on May 23, 2006 wherein he described recommendations for implementing a new SECMARK network control monitor in conjunction with SELinux. Morris clarified the relationship between SECMARK/CONNSECMARK, SELinux, iptables, and the Linux kernel. He wrote in part,

"This secmark field is not specific to SELinux, or even iptables. It can potentially be used by other security subsystems and labeling mechanisms if required in the future."

Morris clearly intended for SECMARK and CONNSECMARK to be utilized as both stand-alone filters in and of themselves, and used in combination with SELinux capabilities to create more robust solutions when warranted. It was never intended as a function available only in SELinux, and in fact quite the opposite is true.

Morris goes on to describe how iptables may be used to "select and label packets" and then use SELinux to "enforce security policy using these packet labels." Morris expounds on how SELinux can be used in the enforcement of security policies, while iptables may use SECMARK to mark packets under various circumstances - independently of SELinux - and SELinux may then decide what to do with the marked packets. He further states at one point, "...use iptables to select and label packets...." And finally, it can't get any more clear cut than this statement, "... a new field called secmark was added to the sk_buff structure used by the kernel to encapsulate network packets,...."

sk_buff is the socket buffer, a part of the Linux kernel. It is basically part of the kernel's API. nfmark (netfilter mark) is an example of one of the functions contained in sk_buff. There are more interesting tidbits in Morris' post. If you want to dig beyond the tip of the iceberg and read the entire document, look here: https://james-morris.livejournal.com/11010.html

The whole point of my post here is that many online articles describe SECMARK as a component of SELinux, but that is not correct. However, it is true that its intent has always been to act as a flag which could then be actioned upon by SELinux.

Morris also wrote an email to David S. Miller and Patrick McHardy in April 2006 where he explained the purpose and his thought process on SECMARK. It read in part,

"At the SELinux developer summit, there was discussion of a different approach (sorry, not sure exactly who came up with it initially), where we instead use iptables to mark packets with security contexts, then allow the core SELinux code to act on those markings.

A nice side-effect of this approach is that it does not require any significant changes to the Netfilter code, as the markings are made at the network layer via Netfilter and then interpreted at the socket layer via the security module.

An initial idea was to make use of nfmark for this, however, it appears to be the wrong approach. nfmark is used for and by the networking code, configured by the admin for e.g. routing, packet classification etc. If we also use nfmark for SELinux, then once SELinux is enabled (the default case for two distributions), the admin will not be able to reliably use nfmark; and nfmark manipulations will also screw up SELinux MAC. From a design point of view, security markings should be distinct from network markings: the former are used to implement security policy, the latter to implement networking policy (e.g. routing).

So, I propose to introduce a secmark field (per the patch below), which is only present when enabled as a sub-feature of LSM [1]. That is, it does not have any effect at all for the default kernel. As an integer field, it also does not require the kind of lifecycle management assoicated with security blobs, which becomes invasive for skbs."

Note: SELinux is a security module; Security-Enhanced Linux (SELinux). AppArmor is another popular model. They are different solution models and differ substantially from one another.

End Notes

[1] LSM = Linux Security Modules; an infrastructure that supports security modules (ref: https://www.kernel.org/doc/htmldocs/lsm/framework.html)

References

Smalley, Stephen D. (n.d.). NSA Security-Enhanced Linux (SELinux). National Information Assurance Research Laboratory. National Security Agency (NSA).
https://www.nsa.gov/Portals/70/documents/what-we-do/research/selinux/documentation/presentations/2006-ottawa-linux-symposium-bof-presentation.pdf

NB Networking. 25 September 2015. SELinux Wiki. http://selinuxproject.org/page/NB_Networking

Morris, James. 16 April 2006. Security marking. e-mail. https://lwn.net/Articles/180104/

Morris, James. 29 January 2008. security: add iptables "security" table for MAC rules. E-mail. LWN.net, https://lwn.net/Articles/267140/