Mental Rootkit

Ubunto 9.04 – otherwise known as Jaunty Jackalope – has been out for almost 3 months now and there has been way too little mention of the improved SELinux integration. The new release includes much more comprehensive policy coverage, packages that more closely track Debian, MCS by default, and many other features. I was only peripherally involved (Josh and Caleb did the bulk of the work this time), but since Tresys sponsored a good bit of the development I’ll take some of the credit by association.

Installation is amazingly easy. After doing a normal Jaunty install, simply install the selinux meta package via ‘apt-get install selinux’. That will disable AppArmor, install all of the needed packages, and enable the SELinux kernel module by default. After rebooting – which does the initial file labeling – SELinux should be enabled and ready to go. By default permissive mode is set. Once you’ve tested the system in permissive enforcing can be set with the command ’sudo setenforce 1′.

Look for updates to both the selinuxproject.org wiki and the Ubuntu SELinux wiki in the next few weeks.

JOANNA RUTKOWSKA – from Invisible Things Lab – has posted her keynote slides from EuSecWest. Good overview, but nothing new if you’re familiar with the work from the Trusted Computing Group (TCG) and TXT.

She did link to a paper from Bernhard Kauer that I hadn’t seen before – “OSLO: Improving the security of Trusted Computing”. The paper is a bit out-of-date and many of the TPM attacks have been fixed in TPM 1.2 and later, but it does a nice job of illustrating the difficulty of effectively using a TPM – especially with a static root of trust (SRTM). Summary from the paper:

We found weaknesses in bootloaders and the possibility of a simple hardware attack against TPMs. Furthermore by just flipping a single bit we disabled the CRTM and any PCR extension from the BIOS. These cases show that current implementations do not meet all three conditions of a trust chain.

In summary, we conclude that current BIOSes and bootloaders are not able to start systems in a trusthworthy manner. Moreover, TPMs are not protected against resets.

It is going to take a while for system designers to not only understand the implications of this technology but create implementations that can effectively and securely leverage it’s potential.

It seems that most of the tech world has realized that Mac OS X is not actually immune to viruses and malware as some previously claimed. The announcement from SecureMac and Intego about two newly identified malware examples should convince any remaining deniers (via F-Secure).

The vulnerability of Mac OS X to malware is, of course, not surprising to anyone with knowledge of computer security. The fundamental problem is that the most used OS security controls in OS X are standard Discretionary Access Control (DAC), which can do nothing to protect against exploitable software. Until the day we can produce completely correct software – which doesn’t appear to be any time soon – we are going to need stronger security mechanisms than DAC.

Looking at the second vulnerability linked above, called PokerStealer.A, demonstrates the problem. Essentially, PokerStealer.A prompts the user for a password when started to discover the password for the current user. The F-Secure analyst Mark G. states:

It checks the provided password to see if it matches the username of the machine. If not, it will ask again. It needs the user’s password to continue.

What happens behind the scenes is the following: it enables the SSH of the infected machine by running; it acquires the local IP address, subnet mask, private IP address of the router (domain), public IP address by querying via the Internet; it gets the version of OSX, recovers its hash and saves it to a file named "secret_file".

After all the necessary information has been gathered it then sends the information to a specific e-mail address with a subject of "Howdy" and the message details include username, password, and IP addresses.

With the e-mailed information, the attacker can perform routines from a remote location through SSH without the user knowing it and may even take control of the infected machine.

The key point here, besides the social engineering part, is that the PokerStealer.A attack succeeds because the application has all of the access of the user that ran the application. This is the problem with DAC: the access of an individual program is not distinguished from the access of the user. There is no reason that most applications need the kind of broad access that allows this Trojan to work. If nothing else, not allowing network access by default to every third-party application would stop this Trojan (which is what Dan does for his xguest SELinux policy in Fedora 9).

I’m not the only one that has noticed this: Dino Dai Zovi suggests in a ZDNet blog:

Sandbox policies for Safari, Mail.app, and third-party applications.  Code execution vulnerabilities aren’t the only kind of vulnerabilities and good sandbox policies for security-exposed applications can help mitigate the exploitation of code execution and other vulnerabilities in these applications.

The sandbox policies he is referring to are the new security mechanisms in 10.5 based on the TrustedBSD project, a sister project to SELinux. Dino makes several other good suggestions aimed at making software harder to exploit, but I was particularly glad to see the continued recognition that per-process mandatory access control is important.

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.
Read more…

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=0x05 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=0x05 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=0x05 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.