My co-worker, Serge Hallyn was in town the other day, so he popped by to tell us about file capabilities. I think that file capabilities are the missing link for making capabilities useful and I’m tremendously excited that they will soon be generally available. File capabilities are a feature that allow a system administrator to add specific capabilities to an executable (stored in extended attributes, set using setfcaps or setcap). This in turn means that if the necessary capabilities exist then executables no longer have to be setuid root. Rather than having daemons start as root and drop privileges, if the proper file capabilities are set, they can just start as their regular user. The canonical example is ping. It is currently setuid root but it only needs the cap_net_raw capability. Using file capabilities, you can remove the setuid bit, add the cap_net_raw bit and you decrease the chance that ping can be used to subvert your system. Chris Friedhoff has an excellent page[1] which describes how to use file capabilities in more interesting ways, for example on X and Samba.
Here are the notes that I took from Serge’s discussion:
3 sets of capabilities
I - inheritable (have after exec)
P - permitted set
E - effective set (right now)
capset()
can remove from inherited set but can only put them in if you have CAP_SETPCAP
can remove from effective set and can put them back in if in permitted set
can remove from permitted set but can’t put them back in
pI’ = pI
pP’ = union(intersection(pI,fI), fP)
pE’ = fE ? pP’ : empty set
The capabilities in the file’s permitted set (fP) are known as the ‘forced set’ because the process will wind up with the capability regardless.
64 bit capability set now in -mm. This will make it easier to add new capabilities to hopefully further reduce the need for setuid programs.
Capabilities stack with SELinux and AppArmor implements capabilities directly in their LSM (hopefully they will pick up file capabilities), so you are not faced with an either/or decision about using capabilities. Capabilities allow you to grant additional privilege where LSMs can only further restrict privilege.
So if you want to experiment with it, grab the latest 2.6.24 release candidate. If you are a Fedora user, you can enable the rawhide repository and install the rawhide kernel. You will still have to install your chosen user space package manually, either from kernel.org[2] or from KaiGai Kohei who has updated libcap[3] to add setfscaps. He is now pointing off to a Google site which is inaccessible to me but his old packages still seem to work.
If you are interested in this topic, I highly recommend Serge’s excellent article on developerWorks: POSIX file capabilities: Parceling the power of root[4]
UPDATE: libcap2 supports the 64 bit capabilities that are now in the -mm tree. For the vanilla 2.6.24-* tree, use libcap1 from http://www.kernel.org/pub/linux/libs/security/linux-privs/libcap1/
UPDATE 2: libcap 2.03 supports both 32 and 64 bit capabilities.
[1] http://friedhoff.org/fscaps.html
[2] http://ftp.kernel.org/pub/linux/libs/security/linux-privs/libcap2/
[3] http://www.kaigai.gr.jp/
[4] http://www.ibm.com/developerworks/linux/library/l-posixcap.html
The NSA has published their Guide to the Secure Configuration of Red Hat Enterprise Linux 5[1]. This is an excellent document that describes best practices for securing a Linux system - tailored to Red Hat Enterprise Linux 5. It starts with best practices, such as, encrypt transmitted data and minimize installed software. It then follows up with exact configuration recommendations, for example, the exact configuration option to prevent root from logging in directly via ssh (Section 3.5.2.6). They do a pretty good job describing the rationale for making the changes that they recommend (”The root user should never be allowed to login directly over a network, as this both reduces auditable information about who ran privileged commands on the system and allows direct attack attempts on root’s password.”). If you are responsible for the security of any Linux system (whether as a developer or an administrator), I highly recommend taking a look at this document and thinking twice about any decision that you make that runs counter to these recommendations.
[1] http://www.nsa.gov/snac/downloads_redhat.cfm?MenuID=scg10.3.1.1
According to HP Backs Red Hat in Government Biz Bid [1], “Lillestolen said, however, that HP has gone further than Big Blue by certifying a wider range of hardware.” Hopefully, this is just a mistake in the reporting and HP isn’t actually making such outrageous claims. As you can see in the Validation Report [2], HP tested on
- Intel Xeon (HP DL360)
- Intel Xeon/Pentium (HP Compaq dc7600)
- Intel Xeon EM64T (HP DL360) - dualcore
- Intel Xeon EM64T (HP DL360) - singlecore
- AMD Opteron (HP DL 385) – singlecore
- AMD Opteron (HP DL 385) - dualcore
- AMD Opteron (HP DL 145) - singlecore
- Intel Itanium 2 (rx 3600) – dualcore
- Intel Itanium 2 (rx 2620) – singlecore
According to IBM’s Validation Report [3], the following platforms were tested:
- System z Hardware: z900/z9 Host Operating system running: z/VM 5.1 or z/VM 5.3 within a PR/SM logical partition
- Opteron Hardware: model 3455, Bladecenter LS-21
- System p Hardware: p5 720 (9124), Bladecenter JS-21 Host system running: LPAR partition
- System x 3550, HS-20 Bladecenter, HS-21 Bladecenter Hardware: Intel Xeon with Hyperthreading and EM64T
In both cases, 8 different machines were tested. However, IBM tested radically different architectures, whereas HP tested minor variations of a few themes. For those of you not familiar with IBM terminology, the IBM evaluation tested a mainframe, a POWER system, a POWER blade, a rack-mounted Opteron system and Opteron blade, two Intel Xeon blades, and a rack mounted, dual-core Intel Xeon server. For those unfamiliar with HP’s line of hardware as I am, their website shows that HP tested one desktop and 3 rack-mountable Intel Xeon systems, three rack-mountable Opteron systems, and two rack-mountable Itanium systems. None of the systems listed in their Validation Report is a laptop contrary to Lillestolen’s claim.
I am glad to see that RHEL5 has received so much testing in the MLS configuration. Perhaps widespread knowledge that many systems were tested in many configurations will help speed the adoption of the MLS configuration in the defense industry. But I hope that reporters won’t let HP get away with making such wild statements that are easily refutable via on-line documents.
[1] http://www.internetnews.com/ent-news/article.php/3708611
[2] http://www.commoncriteriaportal.org/public/files/epfiles/st_vid10165-vr.pdf
[3] http://www.commoncriteriaportal.org/public/files/epfiles/st_vid10125-vr.pdf
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
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
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.
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.
