Open Source Security
Welcome at » 2007 » October

RSA London is going on this week and professional blogger David Lacey is blogging that not much interesting is going on, but that he was very excited to meet Steve Hanna. Steve says that 2008 is going to be the year that Trusted Computing breaks out.[1] I hope he is right! Gartner for 2006 still has Trusted Computing sliding into the trough.[2] But the saddest testament to the slow uptake on Trusted Computing is that Gartner uses it as an example technology to explain two different factors that can cause a technology to have a “Long Fuse” (that is to spend more time than average in the Trough of Disillusionment).[3] I am starting to see some signs that the deep trough that the technology has been in the past couple of years is coming to an end (more on this later) and Steve’s optimism is heartening.

[1]David Lacey, Trusted Computing Hits the Road
[2]Gartner’s Hype Cycle Reports Click on Information Security and look at the table of contents to see where Trusted Computing Platform is listed in the latest Hype Cycle.
[3]Understanding Gartner’s Hype Cycles

Maker Faire was in Austin this past weekend and it was awesome! It was busy but not packed so it was quite pleasant and so there is a reasonable chance that we might see it again next year. (Please, please, please Maker Faire organizers, come back again soon!)

My father-in-law brought his MultiMachine – a general purpose all in one mill that can be made out of junk. He has quite an active Yahoo group so several people who were already familiar with the MultiMachine popped by to take a look. The number one comment was about how easy it looked to build. My father-in-law would really love to see non-profit orgs (NGOs) adopt the design of the machine and take it to distressed areas so that impoverished people could use it as a way to build things and generate income.

There were all kinds of creative and unique bicycles, robots, and musical instruments. There were several electric cars including a Prius conversion. There were yarn spinners, knitters and hand quilters. There was at least one blacksmith with an active forge. The feel of the conference was very open and generous. People were showing off their creations and sharing ways for attendees to learn to make their own. A big Thank you! to the kind woman who helped my 3 year old make her own necklace.

On topics of interest to this blog – open source, there was a very cool display by Rep Rap the Replicating Rapid Prototyper which has the ability to make itself. They say that it is a “practical self-copying 3D printer”. With this device you have the ability to create physical items for yourself and to share with your friends and you can even go a step farther and make another device to give to your friends, so that they can share the physical creations with their friends. Richard Stallman says “Software differs from material objects—such as chairs, sandwiches, and gasoline—in that it can be copied and changed much more easily.” With Rep Rap, at least somethings can now be copied and changed almost as easily as software (though perhaps not yet sandwiches and gasoline).

[1] Maker Faire Blog at http://www.makezine.com/blog/archive/maker_faire/
[2] Multi-machine Yahoo Group with a picture of the multi-machine at http://groups.yahoo.com/group/multimachine/
[3] Rep Rap at http://reprap.org/bin/view/Main/WebHome

One of the most exciting new features in Fedora 8 will be eCryptfs. I downloaded the latest test release of Fedora 8 just to try it out. Mike Halcrow has done a terrific job writing the code, getting it and design documents reviewed and letting people know about eCryptfs. He has written two OLS papers ([1] and [2]) and one Linux Journal article [3] about the design and implementation of eCryptfs. The nice thing about eCryptfs is that it provides per file encryption rather than requiring that the entire block device be encrypted like dm-crypt. This means that if you want to backup the encrypted content and one file changes, on an incremental backup only that one file will be added to the incremental backup, rather than the complete encrypted file system blob.

In Fedora 8, eCryptfs user space packages are not installed by default, so first you have to install them:
yum -y install ecryptfs-utils.i386
and optionally
ecryptfs-utils-dev.i386 for the development libraries.

The eCryptfs module is not loaded by default, so to use eCryptfs, you have to load it, as root:
modprobe ecryptfs

Next you create the confidential directory and mount it, as root:
mkdir crypted Confidential
mount -t ecryptfs crypted Confidential
You are then prompted for a passphrase and given the choice if Ciphers:
Cipher
1) CAST5
2) Blowfish
3) AES-128
4) AES-192
5) AES-256
6) CAST6
7) Triple-DES
8) Twofish

Next enter the Confidential directory and start typing in your secrets:
vi Confidential/donttell.txt
and BAM! AVC denials creating the .swp file and you can’t save your file. The Confidential gets mounted as system_u:object_r:unlabeled_t:s0 which vi is not permitted to write to. You have to mount with the option context=system_u:object_r:user_home_t:s0 in order to be able to create files in the Confidential directory when SELinux is enforcing.

Mike’s Linux Journal article has a few more hints on how to customize your .ecryptfsrc file and use ecryptfs-manager which I highly recommend. The ecryptfs-utils package is totally void of man pages and other useful documentation which I fully expect will be remedied in short order. Mike has done a lot of work with the IBM internal Linux Open Client to make eCryptfs totally transparent to the end user. It looks like some of the code and binaries made it into Fedora 8 but the level of integration is not complete. Hopefully, this is something that Mike and the Fedora community will agree to in Fedora 9.

[0] eCryptfs home page at http://ecryptfs.sourceforge.net/
[1] OLS 2004: Demands, Solutions, and Improvements for Linux Filesystem Security at http://www.linuxsymposium.org/proceedings/reprints/Reprint-Halcrow-OLS2004.pdf
[2] OLS 2005: eCryptfs: An Enterprise-class Cryptographic Filesystem
for Linux
at http://ecryptfs.sourceforge.net/ecryptfs.pdf
[3] eCryptfs: a Stacked Cryptographic Filesystem at http://www.linuxjournal.com/article/9400

If you are interested in security and security metrics, I highly recommend reading Dan Geer’s chart deck on “Measuring Security”. It weighs in at a hefty 426 pages, but it made me laugh out loud in parts and go hmmm. Highlights include p. 108 on “Decision Making” says “*Rational decisions are not enough, *Need to also allow for your preferences”. I really like the model for “Tracking Performance” that he shows for selected security software on pages 154-156, but caution still needs to be applied and meta-information about the numbers is important for full understanding – did the product undergo extensive review one year? are the CVE’s equivalent to each other in severity? etc. Well worth a read and on my list for more more comprehensive study.

[1] Dan Geer, Measuring Security

LWN also weighed in (last week) with an article[1] on Smack and the LSM debate. It should exit from subscriber only status soon (but if you are reading this blog, you should subscribe to LWN, it is the best Linux information that money can buy. Plus they seem to really get security and offer a single site that rolls up daily all of the security updates per distro in a single location.).

There was an amusing snafu in the comments section where drag posted a response to the wrong article and got people thinking about an SELinux policy development plugin for Eclipse. One already exists, SLIDE[2] brought to you by the wonderful people at Tresys.

[1]SMACK meets the One True Security Module
[2]SLIDE

Matt Bishop’s text Computer Security Art and Science is an excellent introduction to the field of computer security. Chapter 13 covers the computer security Design Principles originally laid out in a 1975 paper by Salzer and Schroeder "The Protection of Information in Computer Systems". This is the foundational lore of computer security. The design principles are

  • Principle of Least Privilege – the best known security principle: allow the user to do what she needs to do and nothing more. The trick is knowing a priori what the user needs to do and expressing it concisely.
  • Principle of Fail-Safe Defaults – if it is not explicitly allowed, deny it.
  • Principle of Economy of Mechanism – security should be as simple as possible and no simpler.
  • Principle of Complete Mediation – all security decisions (object accesses) should be checked.
  • Principle of Open Design – security cannot rely on obscurity.
  • Principle of Separation of Privilege – This principle is defined as “a system should not grant permission based on a single condition.”
  • Principle of Least Common Mechanism – This principle is defined as “mechanisms used to access resources should not be shared”. Bishop additionally says, “This principle is restrictive because it limits sharing.”
  • Principle of Psychological Acceptability – This principle is defined as “security mechanisms should not make the resource more difficult to access than if the security mechanisms were not present.

SELinux’s main strength and the source of its weakness is in its elevation of the Principle of Complete Mediation above all other principles. The requirement for complete mediation and, more importantly, the requirement that the complete set of in-kernel access control decisions be exported and controlled by policy is the source of the great complexity of the policy language and the extremely high level of knowledge needed to write SELinux policy.

Least Privilege is almost impossible to express succinctly for any system of any complexity. The original strict policy tried to define Least Privilege for a default Linux system and was the source of much frustration because users don’t do what you expect them to do and user space programs have not been written with least privilege in mind. The targeted policy focused on a subset of programs on a typical system and didn’t attempt to get to least privilege. Still common actions were denied by the policy. The policy has continued to improve, but still on a default install the user will be presented with inexplicable AVC deny errors for stuff that standard cron jobs are doing in the background.

The real problem that SELinux faces is that the Principle of Psychological Acceptability was almost completely ignored during the design of the system. Or maybe it wasn’t ignored, it just didn’t consider the psychological acceptability level of the “typical” Linux user as being different from the “typical” NSA employee. Who knows? Almost every criticism that you read about SELinux is based on its lack of adherence to this principle.

Almost all attacks on LSM and alternative security modules are based on the fact that many of them fulfill the Principle of Psychological Acceptability (they are easy to use and unobtrusive), but they fall short on one of the other principles, typically the Principle of Complete Mediation and Principle of Economy of Mechanism (they are simpler than is needed to provide true security). Most of the other modules are designed to address tactical issues, to add another layer to the defense in depth so that attackers go off an pester someone else who is easier to attack. For the NSA and other organizations who require SELinux, there is no one else who their attackers are going to go pester. Their attackers are going after the NSA for a reason. The gulf between the requirements of the NSA and that of the typical user are exactly why there is such vitriol in the debate between SELinux and AppArmor and every other LSM. For the NSA, there really is no alternative.

The SELinux community is making strides towards making SELinux easier to use – setroubleshootd is a great start. But ordinary people when faced with even the simplified messages supplied by setroubleshootd will apply the Principle of Psychological Acceptability and just turn SELinux off. It would be nice that even if they were choosing incomplete mediation over complete mediation that they weren’t deprived of the additional security that some of the other LSMs provide.

That is why I am so happy that Linus re-stated his adamant support for the LSM framework. Thank you Linus.

Linus Torvalds has stated rather firmly that the LSM hooks will stay in the Linux kernel. I’m often asked by people who are vaguely aware of the issue (why AppArmor isn’t upstream, why customers can’t easily run Dazuko, why IMA isn’t upstream), why Linus hasn’t expressed his opinion on this strongly before. This is at least the third time that he has spoken clearly and decisively on this issue (Kernel Summit 2001 when he originally proposed the LSM interface, Kernel Summit 2006 when he definitively stated that the LSM interface was staying in, and now “Hell f*cking NO! You security people are insane.”). I wish that I could believe that this will be final but I don’t hold out much hope that the situation will actually improve as far as customer ability to choose to run a particular LSM or for the upstream adoption of more LSMs. The strong anti-LSM stance of a few outspoken and brilliant Linux community members has caused a lot of projects to not even bother to consider proposing their LSMs for inclusion. That is a real shame because the careful and critical review LSMs receive when proposed for inclusion is especially critical for security. There is real customer demand and interest for choice in this space and, my spin on Linus lack of metrics rant, no real reason to deny them this choice.

I have lots of thoughts on this debate so I’ll revisit this topic, but for now that is enough. I’m off to go do a little happy dance about this thread.

KernelTrap has a nice article summarizing the debate. http://kerneltrap.org/Linux/Pluggable_Security