Networking in NSA Security-Enhanced Linux

Break through the complexity of SELinux with a working example that shows how to add SELinux protection to a simple network server.

The system_u user and object_r role are default values for system objects. It wouldn't make any sense for a port to have a real user or role; it's not owned by anyone and it doesn't initiate any actions that require a verdict from SELinux.


A socket is labeled by its associated inode and is categorized as either a generic socket or one of the following socket subclasses:

  • UNIX stream.

  • UNIX datagram.

  • TCP.

  • UDP.

  • Raw (includes ICMP and other non-TCP/UDP).

  • Netlink families.

  • Packet.

  • Key (pfkeyv2).

Subclasses of sockets can be distinguished in security policy, providing for fine-grained control and flexibility over different network protocols:

allow lpd_t printer_port_t:tcp_socket name_bind;

This rule allows only a TCP socket created in the lpd_t domain to bind to a port of type printer_port_t.


IPv4 and IPv6 ports are labeled implicitly within the kernel, as specified by policy. The format for labeling port types is:

portcon protocol { port number | port range }

The following defines a security context for labeling the standard printer port:

portcon tcp 515 system_u:object_r:printer_port_t

Network Interfaces

Each network interface (netif) is labeled with a security context, as specified in policy. Network interfaces are labeled as follows:

netifcon interface context default_msg_context

The default_msg_context parameter is intended to be used for labeling messages arriving on the interface, but is not currently used.

Here are some examples of netif labeling in policy:

netifcon eth0 system_u:object_r:netif_intranet_t [...]
netifcon eth1 system_u:object_r:netif_extranet_t [...]


Under SELinux, a node refers to an IPv4 or IPv6 address and netmask. It allows host and network addresses to be labeled with security contexts via policy.

The format for labeling nodes is:

nodecon address mask context

Here are examples of labeling localhost addresses:

nodecon ::1   ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

Network Hooks and Permissions

Access-control hooks are implemented for every socket system call, allowing all socket-based network protocols to be mediated by SELinux policy. A few hooks are used only for housekeeping, but otherwise, hooks generally are used to check one or more access-control permissions.

As there are a large number of generic socket controls, see Table 1 for the relationships between the hooks, socket system calls and permissions.

Table 1. The Relationships between Hooks, Socket System Calls and Permissions

HookSystem CallSELinux Permission
selinux_socket_sendmsgsendmsg, send, sendtowrite
selinux_socket_recvmsgrecvmsg, recv, recvfromread

Internally, the socket() system call is decomposed into two hooks. The selinux_socket_create hook is used to check whether the process can create a socket of the type requested. The selinux_socket_post_create management hook is used to assign a security label and socket class to the newly allocated inode associated with the socket.

The SELinux permissions also abstract the way system calls and other operations are viewed from a security point of view. Note, for example, that the getattr permission is used for the getsockname() and getpeername() system calls. They are seen to be equivalent security-wise by SELinux. Similarly, all of the sendmsg()- and recvmsg()-based system calls are reduced for security management purposes into simply read and write. For the curious, the code behind these hooks can be found in the 2.6 kernel, in security/selinux/hooks.c.

As sockets are also files, they inherit some of the access controls associated with files. Table 2 lists the file-specific hooks and permissions inherited by sockets.

Table 2. File-Specific Hooks and Permissions

HookSystem CallSELinux Permission
selinux_inode_setattrfchmod, fchownsetattr
selinux_file_lockfcntl, flocklock
selinux_file_permissionwrite, write, readappend, write, read


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Total bewilderment

derekfountain's picture

What a wonderful example of why kernel hackers shouldn't write magazine articles! I really wanted to understand this SELinux stuff, but this is an impenetrable mess.

Here's how not to do it: first, ensure you don't define your audience. I initially thought this was aimed at developers, but now I think perhaps it's aimed at systems administrators. Second, throw in a whole load of acronyms, right the beginning: MAC, TE, RBAC DAC, LSM (trying to ensure you never use them again in the rest of the piece). Then make life hard for the reader by giving a "general form" containing 3 lines, followed by an example containing 1 line. Still with us? Great. Throw in a few more undefined terms, like "security context", "target context" and "source context", then a few references to system calls (a couple of dozen should be enough). Next present a config file that is longer than the source of the program it is supposed to protect, plus tweaks to 3 other obscure files, the purpose of each remaining unexplained. Then throw in a "make" command without explaining that either. Finish up with a set of obscure commands to prove the example works, carefully labelling it as a "simple demonstration". Job done!

Perhaps I'm in a flippant mood this morning. Perhaps it's because I'm an application developer, not a sysadmin. Perhaps I haven't had enough caffeine. Or perhaps, just possibly, this article is written from the inside out, and is therefore only accessible to those who already understand what the heck it's on about.

If you want to understand mor

James M's picture

If you want to understand more about the underlying concepts, I'd suggest looking at the Faye Coker article listed in the resources,

The article is aimed at anyone interested in how SELinux works underneath, and documents a lot of previously undocumented aspects of the networking. I guess it may have been better to drop the introductory section (instead referring to other resources) and include a short glossary.

There is no Faye Cocker article

Anonymous's picture

I looked at that link,

There is no Faye Coker article listed on that page. I did a find on the entire web page for "faye" and "coker", nothing.

Geek Guide
The DevOps Toolbox

Tools and Technologies for Scale and Reliability
by Linux Journal Editor Bill Childers

Get your free copy today

Sponsored by IBM

8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
On Demand
Moderated by Linux Journal Contributor Mike Diehl

Sign up and watch now

Sponsored by Skybot