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

We've covered enough theory now to look at a real example of SELinux policy for a simple network application. Due to space limitations and the complexity of real-world networking, we develop a policy for a simple TCP echo client.

The source code for the client is available at the Web site listed in the on-line Resources for this article. Briefly, it creates a TCP socket, connects to a remote host's echo port, writes some text and then reads it back.

My workstation has two Ethernet interfaces, and in this example, eth0 is on an intranet, and the server I am connecting to has the IP address 10.3.1.2.

Here are the goals of the security policy:

  • Grant the client only the OS access it absolutely needs.

  • Allow the client to communicate only with inetd servers on the 10.3.1.0/24 subnet via eth0.

Policy

The following is an annotated security policy that meets these goals. To use it, install the SELinux policy sources package for your distribution, and cd to the top-level directory (/etc/selinux/strict/src/policy on my workstation).

Create a file called domains/program/echoclient.te, and add these policy entries as shown in Listing 1.

Add the following labeling definitions to the net_contexts file:

# Label eth0
netifcon eth0 system_u:object_r:netif_intranet_t
         system_u:object_r:unlabeled_t

  # Label the internal network.
nodecon 10.3.1.0 255.255.255.0
        system_u:object_r:node_internal_t

Update the types/network.te file:

# Define netif_intranet_t as a type of network
# interface.
type netif_intranet_t, netif_type;

Define a file context for the executable in a new file called file_contexts/program/echoclient.fc:

# Default file context for labeling
/tmp/echoclient -- system_u:object_r:echoclient_exec_t

Compile and load the policy:

$ make load

That's all—the policy is done. It seems like a lot to do, but it gets easier once you're familiar with the various policy files and types of policy entries needed. It also helps to use tools like audit2allow, which takes audit log denial messages and turns them into allow rules. It would be better to use a high-level GUI policy tool for day-to-day policy development; we've taken it step by step here to show how things work.

Testing

Now, build and label the client executable:

$ make echoclient
cc     echoclient.c   -o echoclient

$ restorecon /tmp/echoclient

Verify that it is labeled correctly:

$ getfilecon /tmp/echoclient
/tmp/echoclient system_u:object_r:echoclient_exec_t

______________________

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