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.

Sockets

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.

Ports

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 }
        context

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

Nodes

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 127.0.0.1 255.255.255.255
        system_u:object_r:node_lo_t
nodecon ::1   ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
        system_u:object_r:node_lo_t

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_createsocketcreate
selinux_socket_post_createsocketn/a
selinux_socket_bindbindbind
selinux_socket_connectconnectconnect
selinux_socket_listenlistenlisten
selinux_socket_acceptacceptaccept
selinux_socket_sendmsgsendmsg, send, sendtowrite
selinux_socket_recvmsgrecvmsg, recv, recvfromread
selinux_socket_getsocknamegetsocknamegetattr
selinux_socket_getpeernamegetpeernamegetattr
selinux_socket_setsockoptsetsockoptsetopt
selinux_socket_getsockoptgetsockoptgetopt
selinux_socket_shutdownshutdownshutdown

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_file_ioctlioctlioctl
selinux_inode_getattrfstatgetattr
selinux_inode_setattrfchmod, fchownsetattr
selinux_file_fcntlfcntllock
selinux_file_lockfcntl, flocklock
selinux_file_permissionwrite, write, readappend, write, read
______________________

Comments

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, http://www.linuxjournal.com/article/7864

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, http://www.linuxjournal.com/article/7864

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

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix