Networking in NSA Security-Enhanced Linux
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.
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.
Listing 1. echoclient.te
# Simple echoclient policy for Linux Journal article
# File: domains/program/echoclient.te
# Define the echoclient_t type as a domain.
type echoclient_t, domain;
# Define echoclient_exec_t as a type of executable
# file.
type echoclient_exec_t, file_type, exec_type;
# This is a macro which will allow a correctly
# labeled executable to transition into the
# echoclient_t domain from the staff_t domain.
domain_auto_trans(staff_t, echoclient_exec_t,
echoclient_t)
# Designate which roles may enter the echoclient_t
# domain.
role staff_r types echoclient_t;
# This is a macro which allows the domain to use
# shared libraries.
uses_shlib(echoclient_t);
# Provide the permissions required to run the
# program when logged in via SSH as staff_t,
# allowing diagnostic and error messages to be
# written to the user's tty.
allow echoclient_t sshd_t:fd use;
allow echoclient_t staff_devpts_t:chr_file {
getattr read write };
# Network configuration
# These are the socket permissions required by the
# domain. Note that they are locked down to TCP
# sockets.
allow echoclient_t echoclient_t:tcp_socket {
connect create read shutdown write };
# Allow the program to send and receive TCP messages
# to the echo port. In standard policy, the port is
# labeled as an inetd_port_t as it is one of a group
# of ports managed by inetd. You could modify the
# policy in net_contexts to lock this down to one
# port if needed.
allow echoclient_t inetd_port_t:tcp_socket {
recv_msg send_msg };
# Allow only TCP traffic over the intranet interface.
allow echoclient_t netif_intranet_t:netif {
tcp_recv tcp_send };
# Allow only TCP communication with internal IP
# addresses.
allow echoclient_t node_internal_t:node {
tcp_recvtcp_send };
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.
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
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
| Trying to Tame the Tablet | May 08, 2013 |
| Dart: a New Web Programming Experience | May 07, 2013 |
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- RSS Feeds
- Trying to Tame the Tablet
- New Products
- What's the tweeting protocol?
- Dart: a New Web Programming Experience
- Hey God - You may not be
2 hours 11 min ago - Reply to comment | Linux Journal
4 hours 44 min ago - Drupal is an Awesome CMS and a Crappy development framework
9 hours 23 min ago - IT industry leaders
11 hours 45 min ago - Reply to comment | Linux Journal
1 day 4 hours ago - Reply to comment | Linux Journal
1 day 7 hours ago - Reply to comment | Linux Journal
1 day 8 hours ago - great post
1 day 8 hours ago - Google Docs
1 day 9 hours ago - Reply to comment | Linux Journal
1 day 14 hours ago
Free Webinar: Linux Backup and Recovery
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.




Comments
Total bewilderment
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
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
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.