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.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState