As a security practitioner, you’ve got to love it when your company comes out with a line like “Security is our brand” [1] and the press eats it up. Of course, security has always been our brand and, on the Open Source side, we have done some significant things to prove it. I’m speaking here of our multi-million dollar investment over the course of many years to Common Criteria certify Red Hat and Novell SUSE. We started out at EAL2 with the security functionality defined in our Security Target against the pre-existing security functionality in SLES 8. We got that evaluation done within 6 months when everybody was saying that it couldn’t be done - ‘Common Criteria certification takes years’, ‘open source can’t be certified’ they said. From that ground work, we marched up the value chain to LSPP/RBACPP/CAPP at EAL4+ with RHEL5 when still (after 6 successful evaluations at progressive levels) people were saying that it couldn’t be done (although much more subtly now) - “The lack of this protection might prevent another evaluation target from passing this evaluation.” [2]
Our LSPP evaluation included more hardware platforms in one evaluation (7) than all previous completed LSPP certifications combined. The beauty of the range of platforms certified is that it allows government agencies who need LSPP to also take advantage of the scale-up and scale-out capabilities inherent in Linux. As a tax payer, I love this because it allows government agencies to benefit from the lower TCO that Linux and open source software provide.
The LSPP evaluation, in my eyes, constitutes a revalidation of the open source development methodology because the project included competing and cooperating companies, along with government, distro, and individual contributors who were contributing as a labor of love and because they believe in the necessity of adding this level of security to Linux.
When we completed the LSPP evaluation, I went back and looked at all of the people who had contributed to the Common Criteria certification effort over the years. Just within IBM, the number went into the high double digits. Of course, none of this would have been possible without the dedication and passion for security shown by Novell and Red Hat. And our evaluator was invaluable - the insight, integrity and sheer brilliance of the people working for atsec is without measure or compare.
Security is Our Brand!
[1] http://www.internetnews.com/security/article.php/3708446
[2] http://www.sun.com/bigadmin/features/hub_articles/mls_trusted_exts.jsp
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
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
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.
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
Moments after I posted the previous entry, I received notification that Ulrich Drepper has now published his new proposal[1] to add sha256 and sha512 to crypt. It includes a proposal to lengthen the salt to 16 and allow for the number of rounds to be optionally specified in the salt string. According to the specification, “The maximum length of a password string is therefore (excluding final NUL byte in the C representation):
SHA-256 80 characters
SHA-512 123 characters” [2]
So it looks like we might get a stronger algorithm for passwords widely adopted in the near future.
BTW, I saw this come through the gov-sec mailing list which is a mailing list for Linux adoption by U.S. government. [3]
[1]http://people.redhat.com/drepper/sha-crypt.html
[2]http://people.redhat.com/drepper/SHA-crypt.txt
[3]https://www.redhat.com/mailman/listinfo/gov-sec
Within the past several months, an amazing number of people have asked me about the maximum length of passwords and user names in Red Hat Enterprise Linux and SUSE Linux Enterprise Server. Every one of them says that they have searched for this data and are not able to find it. I’ve searched around too and find it in bits and pieces but not as a consolidated whole. It is funny though (as in things that make you go hmmm), that Solar Designer has written an updated man page for crypt which contains almost all of this data, which is included in the glibc source RPM for SLES but not installed.
On RHEL5, the maximum length of a user name is 31 characters.
On SLES10, the maximum length of a user name is 32.
(Odd results, but try it and you will see!)
Algorithm: crypt
Prefix: none
Maximum Cleartext Password Length: 8
Length of Salt: 2-char (12 bits)
Iterations: 25 (built-in)
Length of Hashed String: 11-char (64bit)
Maximum Length of Hashed Password (prefix + salt + $ + hashed_str): 13-char (0 + 2 + 0 + 11 = 13)
Algorithm: md5
Prefix: $1$
Maximum Cleartext Password Length:
RHEL5.1: 79 (5.1 limit imposed by passwd)
SLES10: 127 (limit imposed by passwd, blames crypt in comment)
Length of Salt: 8-char (48 bits)
Iterations: 1000 (built-in)
Length of Hashed String: 22-char (128bit)
Maximum Length of Hashed Password (prefix + salt + $ + hashed_str): 34-char ( $1$salt$hashed_str ) (3 + 8 + 1 + 22 = 34)
Algorithm: Blowfish (SUSE)
Prefix: $2a$
Maximum Cleartext Password Length: 72
Length of Salt: 22-char (128 bits)
Iterations: 16 (built-in)
Length of Hashed String: 31-char (184bit)
Maximum Length of Hashed Password (prefix + salt + $ + hashed_str): 60-char ($2a$nn$salthashed_str) (4 + 2 + 1 + 22 + 31)
Note that I am still working on experimenting with the formatting of this entry because I find the current presentation relatively unreadable. So this entry may change after it is published.
OSSI submitted OpenSSL 0.9.8 for FIPS 140-2 validation. They have a press release on their home page. They successfully completed a validation of OpenSSL 0.9.7j earlier this year. This is an important validation of the cryptographic strength of OpenSSL. Red Hat has also validated NSS at FIPS 140-2 level 2. Since FISMA was enacted, government agencies are required by law to use FIPS 140-2 validated encryption whenever cryptography is used to protect the security of the system. FISMA explicitly eliminates waivers so these FIPS 140-2 validations are critical for Linux adoption by government agencies.
I just added a link to Alan Robertson’s new blog Managing Computers. I’m glad that Alan is starting a blog because whenever I talk to him, I always learn something new and walk away with a new insight or koan to ponder. I hope that in addition to blogging about Managing Computers, Alan blogs about Managing Communities, because during my limited and short lived involvement in the Linux-HA community I found it wonderfully refreshing how nice people were to each other in that community.
Gerrit is blogging the Linux Kernel Summit this week and his blog entrys are well worth reading, if just for the use of the word kerfuffle. Seriously, there is good stuff there - Andrew Morton on Linux Kernel Quality is especially interesting to me. I had heard that Andrew was tossing around the idea of requiring test cases for patch submissions. That would greatly increase test code coverage and reduce regressions, but based on the discussion in Gerrit’s blog posting, it looks like it would have been dismissed out of hand for requiring to much additional work, if it had even been brought up at the kernel summit. A related topic was brought up during the Documentation session with a proposal to pull LTP tests into Linus’ git tree.
Off the topic of quality, this cracked me up: “The running joke was that long explanations of x86 functionality requested by the s390 people was usually ended with the comment “oh, I understand now, we have an instruction that does that” ;)”
I love this coverage of the Kernel Summit, along with LWN’s coverage, it is better than actually being there!
