Fedora Weekly News continues to be a(n unexpectedly) great source for security content. I’ve recently been cleaning up the backlog of my email and have discovered nuggets of valuable information such as
94% of Fedora 8 installs have SELinux enabled
in Fedora Weekly News Issue 121 (Feb. 18, 2008). Now if you read the article, the number I selected to highlight is the raw number that James got off-list. 47%, 50%, and 74% were also tossed out there. Dan Walsh said that the statistics are misleading but being improved and Yaakov Nemoy says that smolt only measures 10% of Fedora machines. So, they are still working out the details. Even so, what they have measured so far is a quite a bit different from the statistics that we see about enterprise customers. I expect it is probably because Fedora users are satisfied with a completely open source stack and do not install as many 3rd party ISV applications which are not as integrated and do not have application specific SELinux policy. Still, this is an incredibly encouraging statistic. Once the Fedora community has been collecting the statistics a little longer, collects whether SELinux is enforcing or not, and starts publicizing these statistics widely, they may be able to help drive ISV adoption (or at least tolerance) of SELinux which will encourage commercial customers to follow the Fedora wave of early adopters on short order.
P.S. Yes, the title is tongue in cheek with a nod to the guys who participated in the discussion.
In a major validation of the FLASK architecture, the OpenSolaris community has created a new project called Flexible Mandatory Access Control (fmac) to adapt the FLASK architecture to OpenSolaris. (The FLASK architecture that is the basis for SELinux.) Stephen Smalley will be one of the community leads. OSNews picked up the email thread today with some interesting comments.
James Morris notes related work in his blog posting from this morning and offers to help the community preserve interoperability with SELinux.
Personally, I would be delighted to see widespread adoption of the FLASK architecture lead to usability improvements and complexity reduction across the board.
[1] http://www.opensolaris.org/os/project/fmac/
[2] http://www.opensolaris.org/jive/thread.jspa?messageID=204568𱼘
[3] http://www.osnews.com/thread?303491
[4] http://james-morris.livejournal.com/2008/03/05/
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/
Roy Fielding[1] finally quit the OpenSolaris community today, see his resignation letter[2]. The kettle finally boiled over and the realization come to many (but not all) that Sun is publishing their Solaris code for marketing purposes, rather than creating an independent, community-led, open source project with the ability to make real decisions.
It seemed so promising at first: “[T]hey made promises about it being an open development project. … Sun gave up its right to make arbitrary decisions regarding the phrase ‘OpenSolaris’ as part of its public agreement with the community in the form of the Charter. That was a self-imposed restriction in exchange for the benefits of community-driven development, freely made, and cannot be changed except in accordance with the charter itself (for example, by amending or dissolving the charter).” (excerpt from Roy Fielding’s resignation letter) But it was a sham: “The charter has therefore been violated. … Sun agreed that ‘OpenSolaris’ would be governed by the community and yet has refused, in every step along the way, to cede any real control over the software produced or the way it is produced, and continues to make private decisions every day that are later promoted as decisions for this thing we call OpenSolaris.” (excerpt from Roy Fielding’s resignation letter)
To be fair, most developers recognized the community as a sham right away merely based on the copyright and patent assignments required by the contributors agreement[3]. To date, Sun has received 578 patches[4], which represents a rate of 0.6 patches a day (first patch dated 6/17/05, there were some earlier undated contributions). Linus gets more patches while he is brushing his teeth than OpenSolaris gets in a week. Despite Roy’s efforts to build a real community, contributing to OpenSolaris always has been and seemingly always will be, corporate welfare.
For me, the realization that Sun just doesn’t get it, and never will, was crystallized the day I was turned away from an OpenSolaris Users’ Group meeting for refusing to sign an NDA.
It is a credit to the Solaris engineers that a few hearty souls want to soldier on amidst the wreckage: “Nonetheless I believe the time has come for a reboot and I am looking for other like-minded people to stand and form a full Board for positive change.”[5] And others who are even contemplating forking: “We will need to build out our infrastructure so that we can host development, mailing-lists and etc.. Once that is done, we will need to make the case to start moving development to the new organization/infrstructure. This will mean that even Sun employees will have to chose to move their development work to a community ‘controlled’ development infrastructure.”[6] It is to them, that I dedicate the title.
[1] http://en.wikipedia.org/wiki/Roy_Fielding
[2] http://mail.opensolaris.org/pipermail/ogb-discuss/2008-February/004488.html
[3] http://www.opensolaris.org/os/about/sun_contributor_agreement/
[4]http://www.opensolaris.org/os/bug_reports/request_sponsor/
[5] http://mail.opensolaris.org/pipermail/ogb-discuss/2008-February/004487.html (Yes, the author of this email is a Sun employee.)
[6] http://mail.opensolaris.org/pipermail/ogb-discuss/2008-February/004477.html
A longstanding limitation of doing remote attestation between “strangers” has been eased through some experimental work that Hal Finney recently announced on the TrouSerS user’s list. Hal has announced that he has created a Privacy CA at PrivacyCA.com. Question 2.1 of the TrouSerS FAQ contains a graphic showing the prerequisite pieces for doing remote attestation. Hal has filled in the Privacy CA and notes that Infineon does supply the Endorsement Credential. He also provides a “test and debug mode” so that users of other TPMs can still experiment with the service without the guarantee that they are using real TPMs. Up to now, attestation keys had to be exchanged via sneaker net (manual exchange and verification before attestation was possible) to enable machines to do remote attestation. Hal’s announcement represents a great leap forward in the usefulness of TPMs.
1. http://sourceforge.net/mailarchive/forum.php?
thread_name=da7b3ce30801131643j74be4064l52daa8c0e90efa83%40mail.gmail.com&forum_name=trousers-users
2. PrivacyCA.com
2. http://trousers.sourceforge.net/faq.html#2.1
Oh boy, I thought I had quibbles with the news story on the Coverity announcement yesterday and today someone points out the worst piece of yellow journalism that I have seen in quite some time: Open Source Code Contains Security Holes. First the title is atrocious and this quote “the popular open source backup and recovery software running on half a million servers, were all found to have dozens or hundreds of security exposures and quality defects” may (have) be(en) accurate, but without context sounds worse than it really is. The truth, as George Wilson said, is that this is an article along the lines “And in other news, fire is hot and water is wet.” I personally consider this irresponsible journalism. They had to willfully ignore older stories based on information from Coverity and Carnegie Mellon such as Open Scrutiny of Open Source Code which contains the nugget “The average defect rate of the open source applications was 0.434 bugs per 1000 lines of code. This compares with an average defect rate of 20 to 30 bugs per 1000 lines of code for commercial software, according to Carnegie Mellon University’s CyLab Sustainable Computing Consortium.” This is simply yellow journalism whose primary intention is to drive traffic and raise the ire of open source fans! Harrumph! Outrageous!
Note to Charles Babcock: software has bugs, even security bugs. If you want to drive down the number of bugs in the software that you are using, use open source.
This type of crappy response comes up almost every time Coverity announces a significant improvement. See this similar news story from ZDNet back in October 2006: Most open source is better.
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
Current and former co-workers, Kent Yoder, Dave Challener, Ryan Catherman, Dave Safford, and Leedert van Doorn have written a book called A Practical Guide to Trusted Computing. It’s now available for pre-order on Amazon and will available on Jan. 7, 2008. The authors have been instrumental in the creation of the TCG specs and key open source software, for example, Dave led the TSS Working Group for years and Leendert was on the Board of Directors. I reviewed an early copy of the book almost exactly a year ago. My favorite parts of the version that I read were the chapters on TSS along with the sample code for how to use the TSS API and the chapter on use cases for Trusted Computing (for the sheer fun of it). I think that it definitely lives up to its billing as a practical guide and it provides a complete grounding in the concepts of trust, attestation, measurement, etc. that are foundational to Trusted Computing. It is very readable and is a faster read and shorter than it seems because of the reference information included. I haven’t yet seen the ultimate version of the book, but I’m eagerly awaiting my copy from Amazon. Congratulations to the authors for sticking through the long haul and providing such a useful book!
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
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
