Mental Rootkit

For the last few months I’ve been working on a new project, called FreeIPA, that I’m very excited about.

FreeIPA currently consists of:

• Linux (currently Fedora)
• Fedora Directory Server
• FreeRADIUS
• MIT Kerberos
• NTP
• DNS
• Samba
• Web and commandline provisioning and administration tools

The goal of the first version is to create a server that an administrator to quickly install, setup, and administer that will provide centralized authentication and identity management. Many people already create something similar to this for their own networks. Unfortunately, creating a custom solution is time consuming to do properly. FreeIPA will be able to provide a system that is significantly better integrated, debugged, and polished than the normal one-off solution.

The next version will be much more ambitious. We will began tackling cross-platform security policy management and centralized auditing.

The project is just getting started. We have several developers and what I think are some good plans for a first version. We are, of course, looking for more developers (or admins with strong feature ideas). If you’re interested have a look at the website and join the mailing-list.

Skywing (author of the Nynaeve blog that I mentioned recently) responded in the comments to my recent post about the new Vista integrity controls:

“You should technically be able to configure a Vista system where low integrity processes don’t have any sort of access to certain directories (like your documents directory, or whatnot). It’s not the default configuration, though, and the default OS tools (icacls.exe) do not appear to support specifying a deny-read policy with the integrity level ACE, only the default deny-write (so you would likely need to write a custom tool to do the work).”

It’s probably possible to do this in some way, but it doesn’t fit with the hierarchical integrity model. The idea of that model is that lower integrity processes should always be able to read high integrity data because is should be safe. The model is only concerned with protecting processes from malicious input (i.e., lower integrity data), not with keeping your personal data off the internet.

Now I don’t really care whether the model they enforce is pure or not per se. Rather, my point is that when you start tweaking things in an ad-hoc way then you lose any advantage you had by adopting a well understood model. These security models are designed to, within limits, allow you to conclusively prove that certain types of security breaches aren’t possible. Unfortunately, it’s not hard to tweak things to the point that these proofs are no longer valid.

I just wonder why the Vista developers didn’t choose a better model to start from. Skywing also said:

“This still doesn’t give you the ability to differentiate between two different “lesser trusted” processes, though (at least not without creating separate user accounts, which is what we’re trying to avoid here).”

This is definitely true and one of the major problems with a security model with limited expressive power. In the real world multiple process that accept untrusted input need to be separated from each other (e.g., firefox, evolution, and gaim pidgin). SELinux lets you express that separation directly while the hierarchical integrity levels don’t.

Frank Mayer (my old boss and co-author) wrote an artice called “Five ways SELinux may surprise you“. Nothing particulary new for anyone familiar with SELinux, but still a nice article. As usual, he gets right to the heart of why SELinux is important:

“A colleague of mine once elegantly articulated a phenomenon that is still common today: We tend to build sophisticated security solutions and applications on top of network and operating system technology that is weak and vulnerable. So while the application may have good security functionality, the overall system (and hence the application) remains vulnerable to attacks to its underlying infrastructure (Trojans, viruses, privilege escalation, etc.). She called this phenomenon “fortresses built upon sand.” The strongest castle walls are useless if they are undermined by the foundation upon which they sit.”

You can read a more in-depth examination of why strong security at the operating system level is important in the “The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments” by the original developers of SELinux.

BigAdmin recently ran a comparison article by Glenn Faden about Solaris Trusted Extensions and Red Hat Enterprise Linux 5 that I think deserves some response. Partially because of factual errors about SELinux in the article and partly because I think that there are some big picture misconceptions.

Mr. Faden starts off with:

“Sun Microsystems, Inc. and Red Hat have both submitted new versions of their trusted operating systems (OS) for Common Criteria (CC) certification evaluation. While these systems are being evaluated against the same CC protection profiles and at the same evaluation assurance level, these systems differ in significant ways that affect how a customer might choose to use such systems.”

The biggest misconception of this article that I want to address is that Red Hat Enterprise Linux 5 is a “trusted operating system”. It is not and hopefully never will be. Instead, Red Hat Enterprise Linux is a general purpose operating system that can meet the same requirements that traditionally required a special-purpose trusted operating system. This distinction may seem small, but it has large implications on the relevance and long-term viability of Red Hat Enterprise Linux and SELinux.
Continue Reading »

Someone pointed me to a blog entry titled “Do the Fedora Developers run with SELinux enabled ?“. He lists some SELinux avc messages that he is seeing and wonders whether anyone is testing SELinux in Fedora. The real question he should be asking, however, is what is wrong with his system. I would have sent him a private message or commented on his blog, but I could not find any contact information and he has comments disabled. If anyone knows the author of this blog please send me an email.

Here are the messages he is seeing (audit2allow output):

allow NetworkManager_t file_t:file read;
allow cupsd_t file_t:file read;
allow depmod_t modules_object_t:file unlink;
allow dhcpc_t file_t:file getattr;
allow fsadm_t file_t:file { Busy DriveReady Error LastFailedSense=0×05 SeekComplete read };
allow getty_t var_log_t:file write;
allow hald_t file_t:file read;
allow hald_t mono_t:dir getattr;
allow hplip_t file_t:file read;
allow logwatch_t file_t:file read;
allow lvm_t unlabeled_t:chr_file getattr;
allow pam_console_t file_t:file read;
allow readahead_t unlabeled_t:file read;
allow rpcd_t file_t:file read;
allow snmpd_t reserved_port_t:tcp_socket name_bind;
allow system_mail_t file_t:file { DriveReady Error LastFailedSense=0×05 SeekComplete read }; < -- is this a bug ?
allow unconfined_t lib_t:file { DataRequest DriveReady SeekComplete execmod }; <-- is this a bug ?
allow unconfined_t user_home_t:file execmod;
allow vpnc_t file_t:file { DriveReady Error LastFailedSense=0×05 SeekComplete getattr read }; <-- is this a bug ?

Most of these messages indicate labeling problems. Relabeling should take care of almost all of them (”touch /.autorelabel” and reboot). I don’t know why the files are mislabeled, but it might be the drive errors that audit2allow misinterpreted as permissions.

To answer his question - yes, many Fedora developers run with SELinux enabled and actively look for errors. More testers and testing is always needed, however. In particular, if you see labeling problems (indicated by file_t and unlabeled_t in avc messages) and have not run with SELinux disabled please post about it on the fedora-selinux list. We would like to get to the bottom of these labeling issues that crop up occasionally.

Oh, and if he was using setroubleshoot he would have gotten a user friendly message explaining the problem and how to fix it.

Several people have noted that Ross Anderson’s book “Security Engineering” is now available for download. As you can see from the table of contents this book covers a lot of topics:

1. What is Security Engineering?
2. Protocols
3. Passwords
4. Access Control
5. Cryptography
6. Distributed Systems
7. Multilevel Security
8. Multilateral Security
9. Banking and Bookkeeping
10. Monitoring Systems
11. Nuclear Command and Control
12. Security Printing and Seals
13. Biometrics
14. Physical Tamper Resistance
15. Emission Security
16. Electronic and Information Warfare
17. Telecom System Security
18. Network Attack and Defense
19. Protecting E-Commerce Systems
20. Copyright and Privacy Protection
21. E-Policy
22. Management Issues
23. System Evaluation and Assurance
24. Conclusions
25. Bibliography

Any book that deals with “Nuclear Command and Control” has to be good.

In order to prevent this from being just another “me too” post devoid of original content, I thought I would link to another excellent computer security book that is available for download. Morrie Gasser’s “Building a Secure Computer System” is also freely available, though it is not in print any longer. Gasser’s book is more narrowly focused on creating secure operating systems, which means that it can go into more depth. It was published in 1988, so some of the detail is dated, but it holds up well and provides an introduction to the issues and techniques used in secure operating systems. Gasser has a very clear and direct writing style and the ability to see straight to the most important issues. For example, here is an excerpt from a section titled “Security is Fundamentally Difficult”

Why are computer systems so bad at protecting information? After all, if it is possible to build a system containing millions of lines of software (as evidenced by today’s large operating systems), why is it so hard to make that software operate securely? The task of keeping one user from getting to another user’s files seems simple enough—especially when the system is already able to keep track of each user and each file.

In fact, it is far easier to build a secure system than to build a correct system. But how many large operating systems are correct and bug-free? For all large systems, vendors must periodically issue new releases, each containing thousands of lines of revised code, much of which are bug fixes. No major operating system has ever worked perfectly, and no vendor of an operating system has dared offer a warranty against malfunctions. The industry seems resigned to the fact that systems will always have bugs. Yet most systems are reasonably dependable, and
most of them adequately (but not perfectly) do the job for which they were designed.

What is adequate for most functions, however, is not sufficient for security. If you find an isolated bug in one function of an operating system, you can usually circumvent it, and the bug will have little effect on the other functions of the system: few bugs are fatal. But a single security “hole” can render all of the system’s security controls worthless, especially if the bug is discovered by a determined penetrator. You might be able to live in a house with a few holes in the walls, but you will not be able to keep burglars out.

If you haven’t read either of these books you have some interesting reading ahead.

It seems like now days when something goes wrong on Linux systems with SELinux it is automatically assumed that SELinux is at fault. Google sums it up nicely in their Picassa FAQ:

Newer distributions may include changes that break Picasa. The SELinux features of Fedora Core are notorious for causing problems with programs like Picasa. If you have problems with Fedora Core, Running Picasa with SELinux enabled may cause problems. You may want to invoke this command: setenforce 0

As tempting as it is to point out that Google has some notoriety itself, I feel that it is more productive to try to understand why the search giant might make such a statement.

I think that it boils down to this: SELinux prevents access and then doesn’t tell anyone. Yeah, yeah, of course there are log files with more detail than anyone could want in /var/log/messages, err I mean /var/log/audit/audit.log. But have you actually looked at these messages? They’re not exactly pretty or designed for the end user. Like I said, SELinux prevents access and essentially doesn’t tell anyone.

None of this would be a problem if SELinux never denied access that a user expected. Now, the current SELinux policies are pretty amazing at covering the access that most applications need. The rub is that sometimes that access is only allowed if the correct boolean is set or files have the correct label. Lots of users have discovered how to perform this configuration, but it still requires staring at those log files long enough to understand them.

Bottom line: users encounter access denials that they can’t diagnose or can’t fix and as a result no longer feel in control of their computers. It is not surprising that users have come to the conclusion that any strange problem is caused by SELinux whether that conclusion is correct or not.

Users will stop blaming SELinux when they can reliably tell whether SELinux is preventing access or not. Helping them allow that access - while giving them some indication of the risks - is the next step, of course, but ust getting to the point where problems that are not caused by SELinux are not blamed on SELinux would be a big win.

There is some good news in all of this. Those log files that I was so happily deriding provide a lot of detail - much more detail than you would get out of any other type of access denial. All of that detail can be repackaged into a message that is a little more user friendly.

A few days ago Dan introduced a tool called Setroubleshoot that does just that. I think that this tool has a good chance of solving some of these issues. First, it reliably reports when SELinux denies access via email or, as you can see below, GUI.

Setroubleshoot then tries to explain - as simply as possible - what access was denied at how to allow that access. Here is the explanation in a spiffy new user interface (I’m really writing this post to show off the user interface improvements):

Like Dan said, we could use some help finishing and polishing Setroubleshoot. Most importantly we need the explanations proofread, corrected, and translated to English (the currently language is only a rough approximation of English). Even if you are not an SELinux expert, just telling us what doesn’t make sense will help. Installing Fedora Core 6 Test 2 or rawhide is the easiest way to get Setroubleshoot for now.

Prentice Hall recently released my book - “SELinux By Example: Using Security Enhanced Linux”. You should buy your copy today (or read it on Safari). Some reasons to buy:

• Covers many of the new SELinux features, including most of those that will be included in Fedora Core 6 / Red Hat Enterprise Linux 5.
• Frank, Dave (the co-authors), and I are all great guys.
• Includes comprehensive coverage of the policy language, object classes, and SELinux utilities including details not documented anywhere else.
• We need the money for the eventual lawsuit from George Lucas for the light saber image on the cover.
• We emphasized why in addition to how. I hope that reading this book will provide some insight in to how to achieve real security with SELinux.
• I spent many hours reading yacc and kernel code to provide some of that comprehensive coverage I mentioned before. I did this with the expectation of millions in royalties.
• Our SELinux technical reviewers were the absolute best we could have hoped for (Steve Smalley, Josh Brindle, and Chris Pebinito) and caught all of the errors I made from misreading yacc and kernel code.

This book was an enormous amount of work that wouldn’t have gotten done without all the support from my co-authors, the technical reviewers, my employeer at the time (Tresys), the staff at Prentice Hall, and of course my wife Sawyer. I’m proud of the result (heck, I’m proud just to have actually finished it) and hope that others will find the book helpful.

I recently discovered that nautilus in Fedora Core 6 will display security contexts thanks to James Anthill. No setting of contexts or MCS support yet, but hopefully that will come soon.

I also discovered that netstat is able to display security contexts. Now, maybe this isn't news to anyone else, but it surprised me.

The documentation is vague on what these security contexts are associated with, but as you can see above it is the security context of the process. While useful, the security context of the socket would also be nice. Currently you have to ask semanage for that information:

Of course, the new secmark and ipsec network labeling options mean that there is still more information that needs to be visible to the user somehow.