Mental Rootkit

Jeremy Maitin-Shepard is circulating an RFC to encrypt the VFS page cache to protect against cold boot attacks. From the RFC, it looks like he is particularly concerned about encryption keys and other security sensitive data stored in the VFS.

This strikes me as a very complex and costly way to protect this data. It also seems very likely to fail to fully address the problem. The Linux kernel is just not designed to separately track, mark, or store sensitive data in a way that makes it practical to encrypt or clear the data. If the sensitive information is anywhere in main memory it is likely that a motivated attacker can craft an attack to obtain the data. Encrypting the VFS might stop some attacks, but not all.

It is much easier to use dedicated cryptographic devices with protected key storage, such as a TPM or one of the newer secure USB sticks. That way the sensitive material is nevery stored in main memory, completely mitigating cold boot attacks. Additionally, the crytographic devices typically have explicit protection against other physical attacks.

Bottom line: adding complexity for partial security solutions doesn’t have enough benefit to offset the cost.

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.