One of the cool new features included in Red Hat Enterprise Linux 5 was VFS polyinstantiation. This work was in support of the Multi Level Security configuration. It allows files to exist in a directory at different security classifications. The subset of files visible to the user depends on the user’s clearance. There is an excellent description of the functionality in both section 4.1.2 of Extending Linux for Multi-Level Security by Klaus Weidner, George Wilson and Loula Salem, as well as Russell Coker’s article Polyinstantiation of directories in an SELinux system.
Now there is an excellent new article on developerWorks by Robb Romans Improving Security with polyinstantiation which describes in simple and detailed terms how administrators can polyinstantiate /tmp (and other world writable directories) to help prevent attacks through /tmp. This technique usable whether or not SELinux is enabled. This article helps answer calls for the complete elimination of world writable directories so as to defeat resource exhaustion attacks (quotas were described as “non-optimal”). One can instead use the method described in this paper to polyinstantiate world writable directories to completely different devices to effectively eliminate the attack. (Yes, they grok TMPDIR. And, yes, unfortunately there are customers who won’t use SELinux.)
So if you were wondering how you can get your feet wet with polyinstantiation, give the steps described in Robb’s article a try.
[1] http://download.boulder.ibm.com/ibmdl/pub/software/dw/linux/lspp-rbac.pdf
[2] http://www.coker.com.au/selinux/talks/sage-2006/PolyInstantiatedDirectories.html
[3] http://www.ibm.com/developerworks/linux
[4] http://www.ibm.com/developerworks/linux/library/l-polyinstantiation/
It’s been a little time since I have written in the blog. I’m still experimenting with how often to post to balance out the drivel with the interesting and the original. I have to say that I’m was a little surprised at how well received the “Best Security News Stories” line has been so I will keep that up. If a story makes me want to run down the halls and tell my co-workers, I’ll post it here instead.
Thanks to LinuxSecurity.com for linking to my blog and adding my blog to the “Featured Bloggers” section of the page. Most appreciated!
The most fun security news story has been covered everywhere but I’m going to include it here anyway precisely because it is so much fun. Joe Barr interviewed Linus Torvalds, Andrew Morton, Ted T’so, and Fyodor and wrote up an article called “Celebrity Advice on keeping your desktop secure”. It includes some excellent tips, like be wary of macro viruses which can also impact OpenOffice (from Ted) and update often, preferably nightly (from Fyodor). Fyodor made the point that the desktop is not the only critical factor for internet security because it can’t save people from themselves - falling for 419 scams, etc. In the end, perhaps the most fun part of the article is the voyeuristic thrill from knowing that Linus is so paranoid about the security of his systems.
With LCA’08 ongoing, there are some interesting news stories appearing on the LCA Planet and it is all too easy to lose far too much time there. I highly recommend the Jim Gettys’ post about the OLPC which reiterates all of the reasons why the OLPC is a critical project for our industry, our children, and our world.
Bruce Schneier’s keynote sounds like it was a good one hitting the high notes on psychology and information: “As security designers we need to address both the feeling and the reality of security” and “‘The way to get people to notice that reality and feeling haven’t converged is information. Information is the best weapon we have.’ In the IT industry, this information is a scarce resource, he said.” It will be interesting to see what he does next to get the industry to produce and publish the data.
On the convergence of security and productivity, zenhabits, a well-known productivity blog, has a guest post on How Productivity Habits Reduced the Impact of Theft … Twice in which Lodewijk’s habit of storing no files on his laptop which he started to improve his productivity has the nice effect of preventing data loss when two company laptops were stolen from him.
And finally, if you don’t already read Bob Blakley’s blog, I highly recommend it. He posts infrequently, but thinks deeply and writes beautifully. Plus he often adds gorgeous photographs. His most recent post is about why he bet his buddy a bottle of Scotch that DRM will be non-existent in the film industry within 4 years. His premise is that in the manner of Robert Rodriguez of old, new artists will make movies on the cheap and release them without DRM. Of course, Robert Rodriguez now makes $100M movies and YouTube is full of movies made on the cheap. That snarky remark aside, I wouldn’t bet against Bob’s vision but I might bet against the timeline. Despite the risk to the existing movie studios, I don’t see them changing their business model until faced with extinction because the New Studio’s massive growth. I would also expect them to pull whatever business tricks are necessary to keep the New Studio down as long as possible.
LinuxSecurity.com is running a fascinating retrospective on the Top 10 SELinux stories of 2007. It makes for fascinating reading and shows some of the issues around SELinux (complexity - #1 and #8), some of the progress that was made in 2007 (secure networking - #4, setools - #6), and some of the critical benefits of using SELinux (SELinux protection of Samba - #2 and #10). The top stories were chosen based on the number of hits they generated. I think that it is too bad that a story about a wiki (#3) beat out any story on the first Common Criteria certification of SELinux (not present on the list at all). The importance of the Common Criteria certification of SELinux in RHEL 5 is that it makes it more easily adoptable by the U.S. government which in turn makes Linux in general more easily adoptable by the government.
http://www.linuxsecurity.com/
http://www.linuxsecurity.com/content/view/133305/169/
Coverity has announced “Rung 2″ and that 11 open source projects have achieved “Rung 2″. This means that they have resolved all Rung 1 defects found by the latest release of Coverity Prevent. There is news coverage at news.com: 11 open-source projects certified as secure which claims that the projects “have been certified as free of security defects”. The 11 projects with bragging rights are Amanda, NTP, OpenPAM, OpenVPN, Overdose, Perl, PHP, Postfix, Python, Samba, and TCL. The Coverity announcement itself says “resolved all of the defects identified at Rung 1″. Looking at the Rung 2 page, it appears to me that there are uninspected defects remaining at Rung 2 which may or may not represent actual defects (and/or actual security flaws), so I’m not sure that the news article’s claim is justified. I also would quibble with the use of the word “certified” which is at risk of becoming overused and rendered meaningless when applied in this context. Despite my quibbles with the news story, Coverity has done us all a major service by exercising their excellent source scanning tools on hundreds of open source projects and reporting the results in a controlled fashion. The 11 projects: Amanda, NTP, OpenPAM, OpenVPN, Overdose, Perl, PHP, Postfix, Python, Samba, and TCL, have done themselves proud by grinding through the reports and fixing defects found. Thanks to Homeland Security for sponsoring this effort, I appreciate this use of taxpayer money. Congratulations and a hearty Thanks! to Coverity and Amanda, NTP, OpenPAM, OpenVPN, Overdose, Perl, PHP, Postfix, Python, Samba, and TCL!
http://scan.coverity.com/
http://www.news.com/8301-10784_3-9843682-7.html?tag=nefd.top
http://scan.coverity.com/rung2.html
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: libpcap 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
If you want to try out some of the Trusted Computing features but don’t want to add them to your running system, check out this version of Knoppix that Japan’s National Institute of Advanced Industrial Science and Technology (AIST) produced with IBM Tokyo Research Lab. It includes Grub-IMA, Linux-IMA, TrouSerS, tpm-tools and TPM Manager(by rub.de). More features are still being developed. Thanks to Seiji Munetoh for pointing this out to me. I downloaded it and tried it on my T42p and it is very clean and slick.
It’s available from http://unit.aist.go.jp/itri/knoppix/index-en.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
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
