Open Source Security
Welcome at » Linux

by George Wilson, IBM Linux Technology Center

I was recently reading through the NIST “Draft Guide to Security for Full Virtualization Technologies” (SP 800-125 draft) []. It discusses various considerations relating to hypervisor security. One section that particularly struck me was the comparison of bare metal vs hosted hypervisors. These are also known as Type I and Type II hypervisors, respectively. The document states that choosing between them is a critical security decision. That started me wondering if it is actually true that Type I hypervisors offer superior security to Type II hypervisors. While a Type I hypervisor may have a small kernel, it relies on and trusts an entire OS instance in the resource-owning partition (Dom0 in Xen parlance) for device access. So while it might at first blush appear that a Type I hypervisor has a much smaller TCB than a Type II, the TCB is really just in a different place. Given imperfect knowledge of the implementations and similar size, complexity, and maturity, it would seem that Type I and Type II hypervisors would in general offer similar security. I can’t find any solid evidence to the contrary. I’d love to hear from someone who can clarify why the Type I vs Type II distinction is in any way a major factor in hypervisor security analysis.

by Rajiv Andrade, Linux Technology Center

Since the foundation of the Trusted Computing Group, previously named Trusted Computing Platform Alliance, the pillars required to win most of today’s security challenges have been heavily developed.

The Trusted Platform Module and the Trusted Software Stack are two of these. Now that we have in our hands the required enablement, the next expected step is to come up with the development of detailed and implementable use cases that were originally envisioned when starting the Trusted Computing Initiative.

The use case presented in this newly published Blueprint exploits the integrity measurement capability that the TPM provides. Other than using a passphrase as an authorization token, it describes how to use a machine’s integrity to authorize access to sensitive files, by means of a key sealed to those integrity parameters.

The parameters include the loaded kernel image, the bootloader and its configuration file, and the BIOS. Thus, if one tries to load a different flawed kernel image, those sensitive files won’t be accessible. It’s also worth mentioning that the bootloader used is able also to measure critical system files (e.g. the libraries placed at /lib), making the job of a rootkit even harder.

The next step is to attest a machine’s integrity using the Integrity Measurements Architecture (IMA) logs that contain a list of measurements of all files accessed by the root user during runtime.

Check it out at:

By Bryan Jacobson, Linux Technology Center.

While Virtualization offers many benefits, there can also be increased security risks. For example, consider a system running two hundred virtual images. All two hundred images are at risk if a flaw in the hypervisor (or configuration) allows any virtual guest to “break out” into the host environment and affect other virtual guests.

sVirt is a project to improve the security of Linux virtualization. Svirt applies the Mandatory Access Control (MAC) features of SELinux to strengthen the isolation between virtual images. Svirt works with KVM/QEMU and other Linux virtualization systems where the virtual image runs as a Linux user space process.

sVirt is a community project, with founding authors from Red Hat: Daniel Berrange, James Morris, and Dan Walsh. sVirt is integrated with libvirt.

One of my favorite sVirt use cases is: “Strongly isolating desktop applications by running them in separately labeled VMs (e.g. online banking in one VM and World of Warcraft in another; opening untrusted office documents in an isolated VM for view/print only).” (From the 8/11/2008 sVirt project announcement at

The project announcement also identifies an excellent design goal: “Initially, sVirt should “just work” as a means to isolate VMs, with minimal administrative interaction. e.g. an option is added to virt-manager which allows a VM to be designated as “isolated”, and from then on, it is automatically run in a separate security context, with policy etc. being generated and managed by libvirt.”.

You can find a 48 minute video of James Morris’s February 2009 presentation on sVirt at

Slides from that presentation are at:

by Klaus Heinrich Kiwi, LTC Security team

The openCryptoki project, a PKCS#11 provider for Linux with support for software and hardware tokens, has released new versions for both the openCryptoki code itself as well as for it’s associated library, libica.

  • Libica-2 is a major cleanup from the previous versions. It has a new API and supports software fall-back (OpenSSL) when no Crypto hardware is present. The current version (2.0.2) has bug fixes and improved code examples.
  • OpenCryptoki 2.3.0 includes support for Libica-2 and has a number of bug fixes and minor improvements

OpenCryptoki is the most common way that PKCS#11-enabled applications (including Java JCE aplications) can exploit cryptographic hardware in a Linux environment.

By Bryan Jacobson, Linux Technology Center.

Tyler Hicks (from our team) recently attended the 5/25-29 Ubuntu Developers Summit for Karmic Koala in Barcelona, Spain.

Some of Tyler’s observations on Security topics:

  • There are quite a few eCryptfs users out there and they are generally happy with the version shipped in Jaunty. Most were using the encrypted home feature, but some wanted more flexibility and had custom setups.
  • eCryptfs encrypted swap is on the roadmap for Karmic.
  • Michael Rooney has been working on graphical applications to compliment some of the eCryptfs userspace tools that are currently bound to the command line.
  • Tyler held an eCryptfs roadmap talk about future eCryptfs features: eCryptfs on top of popular network filesystems, improved key management, and asking for someone interested in completing the eCryptfs GPG key module.

Some general observations from Tyler:

  • Ubuntu would like to be the premier guest available in Amazon EC2.
  • Ubuntu users will soon have a daily build of the virtualization stack available, which is a big win for both the upstream developers and the users.
  • Dustin Kirkland gave a talk on leveraging the cloud for data center power savings.
  • The Ubuntu kernel team committed to removing non-upstream kernel code that no one is using anymore.

See the whole story on Tyler blog at:

Intel has done a study on the costs associated with a stolen or lost laptop. One of the most interesting aspects of the study is that they were able to quantify how much a company saves when the confidential data on the lost laptop is encrypted. The grand total is


saved per lost laptop when the confidential data is encrypted.

I’d recommend using eCryptfs if you are running Linux on your laptop.

by Klaus Heinrich Kiwi, IBM LTC Security Team.

In the Information Security world, authentication and authorization are orthogonal concepts:

  • Authentication refers to the act of correctly identifying an user or other entity, e.g.: making sure a user is who he really say he is. This is often done by associating passwords or keys to user accounts.
  • Authorization refers to the act of granting access from certain users to certain services or resources, e.g.: allowing the user john_doe to read the file /foo/bar. This is usually done by mapping users and groups to resources through the use of permissions.

Kerberos is a network authentication protocol aimed at providing secure and reliable authentication semantics over an insecure (open) network. In a glimpse, it relies on symmetric key cryptography and in a trusted third-party to provide mutual authentication between two entities (called Principals in Kerberos nomenclature). This means that in a scenario where a user is authenticated against a network service, not only the service can be sure of the user identity, but the user can also be sure that he is communicating with the right server. All of this is done without exposing clear passwords or keys in the network.

The Kerberos Protocol is a standard (RFC 4120) with different implementations such as Microsoft’s Active Directory, Heimdal, the AFS kaserver and the Open Source MIT-Kerberos implementation.

LDAP, on the other hand, is an information retrieval protocol for accessing special purpose databases, called Directories. Directories are usually optimized for reading (queries) as opposed to writing operations (inserts), thus they are often used in write once, read many scenarios. This optimization aspect, associated with the hierarchical manner the objects are organized in the database makes LDAP an ideal choice for performing the mapping operations an authorization system needs.

LDAP is also a standard (RFC 4510, RFC 3494 among others) with numerous implementations such as the Open Source OpenLDAP and the IBM Tivoli Directory Server, aimed at enterprise use.

Since release 1.6 of the Open Source MIT-Kerberos (krb5) implementation, it is possible to combine the powerful authentication aspects of the Kerberos Protocol with the reliability and scalability provided by LDAP authorization. Such feature is included in recent enterprise distributions like Red Hat Enterprise Linux 5 series and Novell SUSE Linux Enterprise Server 11 and later, giving those platforms the possibility to benefit from combining the Open Source MIT-Kerberos implementation with the enterprise features of IBM Tivoli Directory Server.

It was with the intention of demonstrating how the above scenario can be achieved that I wrote a Blueprint covering the subject of Using MIT-Kerberos fo IBM Tivoli Directory Server backend.

Blueprints are documents describing the detailed plan of action for a specific task involving IBM hardware or technology. Blueprints bring a step-by-step description showing the exact actions needed to perform a certain task. Those steps are written with the expertise from the Software Engineers who actually work on development, but are also tested for correctness inside IBM labs – an IBM-branded HOWTO.

Besides the above Blueprint, please check-out the other publications I’ve authored or co-authored, including the Enterprise Multiplatform Auditing Redbook and  my Logical Volume Management developerWorks article.

And as always, feedback is greatly appreciated!

Klaus Kiwi

by George Wilson <>, 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:, which BTW is one of the many resources available from the LTC Library here:

By Bryan Jacobson, Linux Technology Center, IBM (

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.

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”.

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 (see

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:

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.)

Mike Halcrow has written a paper on Installing and configuring eCryptfs with a trusted platform module (TPM) key. This paper is available on IBM Systems Information Center along with a bunch of other step-by-step guides.
This paper describes how to use a TPM key directly with eCryptfs. It demonstrates the flexibility of eCryptfs’ pluggable key module framework. Since the TPM wasn’t designed to do bulk encryption, if you actually set eCryptfs up this way, you’ll get pretty low performance, but it is an interesting exercise nonetheless and if you have small bits of information that you want strongly protected, this does provide one good option. I hear that Mike is working on replicating this experiment with a wrappered key which should provide much better performance but requires a little additional code.
In addition to showing how to integrated the TPM with eCryptfs, this paper also contains a step-by-step descriptions on how to do ancillary operations like how to enable encrypted swap in Red Hat Enterprise Linux 5.2 and how to get your TPM up and operational. This side content alone makes the paper useful.