USENIX Update

Two of the Friday sessions I attended were focused on the security. The first was a guru session on SELinux led by Dan Walsh, Red Hat’s lead SELinux developer. SELinux is a labeling and enforcement engine developed by the NSA and released to the public. It has developed a reputation among many sysadmins for being a hassle and is often turned off quickly. In addition to Rik Farrow’s training session earlier in the week (covered in the LISA 10 blog), Dan’s guru session was a chance for admins to learn how to coexist with SELinux.

Dan reviewed the way SELinux labeling works, and how to build SELinux policy by searching for errors in logs and piping the output through the audit2allow program. For example, to find the Booleans that allow the access being denied to an FTP server:

grep ftp /var/log/audit/audit.log | audit2allow

Of course, it’s important to be judicious in adding allows. SELinux is an intrusion prevention system, not an intrusion detection system. As a result, it’s not very good at alerting you that you’ve been compromised. One sign is when a process is looking for access that is unusual.

After taking Rik’s training last year, and attending Dan’s guru session on Friday, I’ve resolved to enable SELinux on my desktop and laptop. We’ll see how it goes.

In the afternoon, Susan Landau gave a talk entitled “Surveillance or Security? The Risks Posed by New Wiretapping Technologies”. Unlike most other sessions, this talk was policy-based instead of technical. In the last decade, especially in the United States, wiretapping has been a widely-discussed issue, making the talk very relevant.

Susan began with a discussion of the challenges imposed on wiretapping mobile phones compared to their wireline counterparts. Wiretapping began almost as soon as the first telegraph lines were strung. General J.E.B. Stuart used wiretapping to learn the movements of opposing armies during the Civil War. Law enforcement use began in earnest during the Prohibition Era.

Relevant laws and judicial rulings from the 20th century were presented as a base to discuss the last 20 years, when wiretapping has been most prevalent. The Communications Assistance for Law Enforcement Act (CALEA) greatly expanded the scope of wiretapping in the U.S., including a requirement that phone switching equipment have wiretap support built in.

As international fiber lines were built in the 1990s, it changed the way many foreign-to-foreign calls were routed, bringing them through the United States. The Foreign Intelligence Surveillance Act (FISA) did not require a warrant for wiretap when one end of the communication was outside the United States, so the NSA lobbied to have this extended to fiber.

Sold initially to aid in kidnapping investigations and later in anti-terrorism efforts, wiretaps have been broadly used (though still, perhaps, not as widely used as during J. Edgar Hoover’s tenure as the FBI Director). Simply understanding the transactional history of phone calls has led to the capture of Khalid Sheikh Mohammed and the London subway bombers. The U.S. Marshals, by locating suspects’ mobile phones, have been able to reduce apprehension times from 42 days to 2 days.

These benefits don’t mean that wiretaps are unequivocally good. Building wiretapping support into infrastructure exposes tapping capability to parties who can compromise the equipment, and reduces the cost of collection such that overcollection becomes a civil liberties concern. Although Susan says the real national security threats are cyberexploitation, she maintains that it’s important for freedom, especially press freedom, remain unrestricted.

SELinux is not the most popular of Linux components.  For many admins, myself included, disabling SELinux is a critical part of the system installation process.  The extra security that SELinux provides is generally seen as not worth the ease-of-use impacts.  Fortunately, the tools used to manage SELinux have matured in recent releases and many in Rik Farrow‘s “Working With SELinux” session on Sunday were those willing to give SELinux another try.

SELinux was developed at the US National Security Agency to enforce the famous Bell-LaPadula model and predictably has more features than most environments require.  The contexts in SELinux have three components: user, role, and type.  In the most common SELinux implementations (specifically Red Hat’s), the type component is the main focus, although Fedora versions after 9 supports confined users.

Rik used a very interesting explanation for the role of SELinux, comparing Linux security to downtown Baghdad.  The Linux kernel, hardware, and parts of SELinux are analogous to the “Green Zone” area that is supposed to be very secure.  The security is managed by checkpoints (syscalls) and applications reside in the less-secured area outside the city.  However, the Green Zone is not impervious to attacks, as mortars and other airborne objects breach the perimeter.  In the same manner, kernel exploits can bypass established security measures.  SELinux is not a panacea.

Most of the issues that people encounter with SELinux revolve around context not being properly set.  This is often the result of moving a file from a directory with one context to a directory with a different context, or with restoring from a backup utility that does not support SELinux context (tar, by default, does not.  Using the ‘–selinux’ flag enabled the SELinux support).

The tools for fixing SELinux context make resolving errors fairly simple.  In many cases, the restorecon command is sufficient to fix the problem.  semanage (command line tool) and system-config-display (GUI tool) can be used to set context for custom directories.  When an error occurs, the setroubleshootd daemon provides notification and suggests the appropriate fix.   aureport is a relatively new tool which makes extracting information from the “ugly” raw log a much easier task.

Having long been fearful of SELinux, I was very excited to gain an understanding and posted a status to that effect on Facebook.  A few friends asked why, and the answer is that SELinux provides a powerful security tool.  It isn’t necessarily useful on single- or few-user desktops, but for servers and kiosks, it provides a layer of protection in addition to traditional file permissions.  It’s important to remember, though, that SELinux can’t fix everything.  Anything an application has permission to access, for example files and databases writable by web applications, can’t be protected by using SELinux.

Rik Farrow’s course has made a daunting concept seem sane and usable.  If you missed this presentation, Rik will be presenting a “The Guru Is In” session on Friday morning.  For future LISA attendees, keep an eye out for this course to be offered again.  You may just change your mind about SELinux.

This morning, I’m attending Rik Farrow’s “Working with SELinux” course. As soon as I walked into the room, it became apparent that I’m in the right place. On the screen was the lead slide of Rik’s show, and the title was “Re-enabling SELinux”. For me, that’s so appropriate, because one of the items on my “new machine” checklist is “disable SELinux”. To me, it’s always been a source of irritation that stopped me from performing actions necessary to administer the machine. The most frustrating part was always that I knew it didn’t have to be like that. I knew that SELinux could be a boon to admins who are always concerned with security. I just didn’t know how to make it work.

SELinux is a extension to the Linux code that was developed by the United States Department of Defense and was released to the Linux community in 2000. It was designed to subscribe to the idea of MLS – multi-level secure. This allows for the categorization of various security levels, such as “secret” or “top-secret”. Most system administrators aren’t concerned so much about “secret” and “top secret” so much as “secure” and “vulnerable”, though.

We can use SELinux’s type enforcement to achieve more secure systems. Contexts are assigned to a multitude of operations and objects, and we constrain them using policies that constrain attempted actions.

The tools used to manipulate SELinux aren’t numerous, but the number of contexts is immense. The hardest part sounds like keeping track of what the contexts should be. Fortunately, SELinux includes ways for us to debug our configuration., such as “setroubleshoot”, which takes the log output of SELinux and formats it so that normal humans can understand it. Audit2allow takes audit log messages and converts them into policy statements, so that perceived failures turn into allowed actions. There are also other ways of configuring SELinux so that it’s useful before it’s really in place.

If you have administered a Linux machine, you may have noticed that there are three possible modes for SELinux. The first is “disabled”, and if you’re like many of the people in the class, this is the one your machines are set to.

The second, “permissive” is much better. This allows SELinux to run and watch access attempts, but not to actually constrain them. This de-fanged mode allows us to see what SELinux would have denied, and change our configuration to allow it, or reconfigure the application as necessary.

The third, “enforcing” is the real mode, which not only watches access attempts, like the “permissive” mode, but also prevents access. Once your configuration is correct, switching from “permissive” to “enforcing” doesn’t require a reboot, only a setenforce command.

After completing this training, I’m very much looking forward to working with it on my machines. My new machines are no longer going to default to “Disabled SELinux”. Instead, I’m going to start evaluating how I can leverage the extra security that it gives.

Rik Farrow’s SELinux Training http://www.usenix.org/event/lisa09/training/tutonefile.html#m8