by George Wilson <gcwilson@us.ibm.com>, IBM Linux Technology Center
Operating system security features are notoriously difficult to explain. Folks who work on security have their own specialized vocabulary, which serves well to communicate concisely with other members of our community. However, it can be difficult to translate concepts into everyday language. Have you ever tried talking about SELinux to those who have never been exposed to MAC? You have to provide a large amount of background material simply to describe what SELinux is, let alone what interesting things can be done with it.
The LTC Security Development Team have developed a number of security features over the years. We’ve discussed them on mailing lists, written conference papers, and otherwise communicated our work to other technical folks. However, explaining the relevance of Linux security features to non-geeks remains a difficulty.
To help address the communications gap, the LTC Security Development Team in concert with the Information Development Team have created a customer-level Linux security brochure. In it, we discuss the various capabilities we have helped bring to Linux distros. Please take a look. It is available for download here: ftp://ftp.software.ibm.com/linux/pdfs/LTC/SecurityTeam.pdf, which BTW is one of the many resources available from the LTC Library here: http://www-03.ibm.com/linux/ltc/whitepapers.html.
By Bryan Jacobson, Linux Technology Center, IBM ( bryan.jacobson@us.ibm.com).
Emily – thanks so much for the guest blogging opportunity!!
On January 5th, Twitter was hacked. “I am high on crack right now might not be coming into work today” came from the account of Rick Sanchez, CNN Anchor and top 20 Twitterholic. 33 high profile accounts were hacked, including those belonging to Barack Obama, Britney Spears and Bill O’Reilly.
All because a Twitter administrator chose a password susceptible to a dictionary attack. blog.wired.com/27bstroke6/2009/01/professed-twitt.html
There are 22 trillion 8 character alpha-numeric passwords.
But studies of actual passwords have found 20% or more to be guessable. A 2006 analysis of 34,000 MySpace passwords found 4% to be dictionary words, and many others were variations on the user’s name, pop culture references like “blink182”, or just adding a “1” to the end of a word or name. The most common password was: “password1”. schneier.com/essay-144.html.
The prevalence of weak passwords creates an environment where internet worms can replicate and spread. For example, a worm that exploits weak passwords is currently mounting a Distributed Denial of Service attack against DroneBL.org (see dronebl.org/blog/8).
Can’t we just tell everyone to start using good passwords? The list of 500 Worst Passwords illustrates how even when users try to form secure passwords, the result may be guessable: whatsmypass.com/?p=415.
Fortunately, on Linux, the problem of weak passwords is curable, using pam_cracklib, which was written by Cristian Gafton.
By default my Ubuntu (Intrepid Ibex) laptop required 8 character passwords, but allowed “arkansas”, other dictionary words, or even the user’s name.
Loading pam_cracklib was easy. The command “sudo apt-get install libpam-cracklib” both installed the package and configured pam_cracklib in /etc/pam.d/common-password.
Now when I try to set a password to “arkansas” I get: “BAD PASSWORD: it is based on a dictionary word”.
A wide variety of guessable passwords were also rejected with “BAD PASSWORD”, including an explanation of the reason:
“testuser1”: it is based on your user name
“arkansas9”: it is based on a dictionary word
“7ytiruces”: it is based on a (reversed) dictionary word
“12345678”: it is too simplistic/systematic
“blink182”: it is based on a dictionary word
“12121212”: it does not contain enough DIFFERENT characters
I did find a couple guessable passwords that pam_cracklib accepted:
“qwertyui” (from the top row of the keyboard).
“qazwsxed” (from keys on the left size of the keyboard)
These words can be added to the file: /usr/local/share/dict/cracklib and they will also be rejected when the pam_cracklib dictionary is rebuilt overnight.
Bottom line: pam_cracklib can improve your system security and reduce the impact of worms. (You can see other pam_cracklib features at The Linux-PAM System Administrators’ Guide, section 6.2. pam_cracklib – checks the password against dictionary words.)
While looking at SSL/TLS in a little more detail, I noticed that many websites default to RC4 which Firefox characterizes “High-grade Encryption” (Tools->Page Info, General and Security Tabs) but which is characterized by Wikipedia as “RC4 has weaknesses that argue against its use in new systems”. RC4 is used because it is much faster than AES. (Web servers can drive 15-20% more traffic with RC4 (128) than with 3DES (EDE). Based on actual results, but YMMV.) Example websites using RC4 include my credit union, a well known online savings account provider, and my 401K provider. Algorithm negotiation is built into the TLS protocol, so you can tweak your Firefox configuration so that your browser no longer offers to use the RC4 protocol. To change your Firefox configuration, surf to about:config and promise to be careful. Search on rc4
security.ssl2.rc4_128 default boolean false
security.ssl2.rc4_40 default boolean false
security.ssl3.ecdh_ecdsa_rc4_128_sha default boolean true
security.ssl3.ecdh_rsa_rc4_128_sha default boolean true
security.ssl3.ecdhe_ecdsa_rc4_128_sha default boolean true
security.ssl3.ecdh_rsa_rc4_128_sha default boolean true
security.ssl3.rsa_1024_rc4_56_sha default boolean false
security.ssl3.rsa_rc4_128_md5 default boolean true
security.ssl3.rsa_rc4_40_md5 default boolean true
Double click on the ones that are marked true to turn them off. Surf out to your bank and voila, you are now (most likely) using AES instead of RC4. (In my Firefox configuration, turning off only RC4 left 3DES still enabled, so if you want to be sure to use AES, you have to turn off the DES options also. Even with DES still enabled, AES-128 was the negotiated algorithm for the financial institutions that I tested.)
Do I think that this is necessary? No, not really. I *do* wonder why an algorithm suite as weak as 40 bit RC4 combined with MD5 is still turned on by default, but in general I believe that crypto is the least of your security worries. But I enjoyed the experiment and I consider this a silent vote for better web security which is now cast every time that I surf out to a secure site.
If you run a webserver, you can tweak your SSLCipherSuite setting to remove RC4 from the algorithms that you offer. See the Apache documentation at http://httpd.apache.org/docs/2.0/mod/mod_ssl.html.
If you are interested in a more rigorous treatment of the performance aspects of this topic, I highly recommend the paper by Li Zhao, Ravi Iyer, Srihari Makineni, and Laxmi Bhuyan entitled Anatomy and Performance of SSL Processing.
My colleagues have written a comprehensive step-by-step guide to enabling disk encryption in your choice of RHEL 5.2 or SLES 10 SP2. This is pretty much as easy as it gets. If you have questions or comments about the paper, they also have an online forum for security discussions. I suggest the PDF version which packages the whole (short) paper up into a single, easily consumable whole.
This document is just the first of the new series of “Linux blueprints” (step-by-step guides for accomplishing specific tasks with Linux) which will be published on the IBM Systems Information Center (Info Center).
Enjoy!
Red Hat Enterprise Linux 5.2 was released today. That is significant news in and of itself, but I am especially excited because it contains Technology Previews of eCryptfs, TrouSerS, and tpm-tools! As Technology Previews, they are not yet supported for production use, but this is the first step to allow for experimentation and time for ripening. I’m happy to see Red Hat’s continued dedication to security. If you try these packages out in RHEL, I’d love to hear of any successes or problems that you encounter.
[1] http://www.press.redhat.com/2008/05/21/red-hat-enterprise-linux-52/
[2] http://ecryptfs.sourceforge.net/
[3] http://trousers.sourceforge.net/
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
