Last modified 8 years ago Last modified on 03/27/09 06:29:05

UABgrid Secure

The UABgrid security effort is about leveraging the grid infrastructure to secure data and communications. Our goal is to describe security and encryption configurations that meet the needs of a variety of grid deployment scenarios, from virtual machines to roaming laptops. The initial focus is on creating a configuration for linux-based systems which meets the requirements of the Data Security Office laptop encryption policy: strong screensaver password and strong boot encryption. The eventual goal is to identify configurations that help ensure data security for all UABgrid system platforms. Trust and security are fundamental to design of grid environments and provide a solid foundation on which to build secured systems.


On the grid, passwords are the most common credential for identifying end-users. While this is true for most system environments today, the grid removes the barriers of distributed password management (keeping passwords synchronized across many resources across many domains) by cleanly separating authentication from authorization. The grid builds trust relationships between authenticating agents (the prompt for your password) and authorizing agents (the guardians of resources) using a public key cryptography infrastructure (PKI). The goal for the grid is to ensure authentication is performed only at the most trusted points in the system and, ideally, as "close" to the user's authority sphere as possible. This approach attempts to make the user as authoritative as possible for their authentication credential (eg. password) by removing the potentials for impersonation. (See the UABgrid Identity Primer for a light overview and references.)

It is reasonably obvious that the more places you store a password and, therefore, the more places that prompt you for that password, the likelihood that your password can be compromised increases. For example, if you are prompted for the same password across many web applications all tied to a common password store, then you need to trust each web site operator not to miss-use the password you just gave them so they could verify it against the backend password store. This approach may be acceptable when all the web applications are run by a single operator whom you trust, but that trust model doesn't scale well when the number of web applications increase and they cross many domains. In that environment, it's best to enter your password only at the most trusted password prompts. This is the goal for grid-based authentication.

In order to discuss the configurations more effectively, we'll use these working security categories:

  • Basic - the standard security of modern, multi-user system environments like Linux. (Note, many web applications are multi-user system environments as well. Most don't have the development history of Unix and deserve some scrutiny of their implementation to see if they meet the basic level)
  • Medium - basic security plus secured data storage on the system, essentially meant to prevent data loss should the system get in the wrong hands.
  • High - as yet undefined, but would be basic + medium + secure cards or other higher-level assurance technologies

Security Categories

Basic Security

The multi-user system model flows from the core of Linux, so all systems can inherently be secured by password-protected accounts.

In order to meet basic Data Security policies, the system should always require authentication before allowing your session to begin. This is typically the case but some configurations automatically log a specific user into the system, which is especially convenient for desktop users. The easiest approach is to disable automatic login (forcing the password prompt) and configure the screen saver to require a password for access to the desktop after an idle event is triggered (eg. an inactivity timeout or, as is common for laptops, a suspend/resume).

Todo: document the account login and screen saver configuration for openSUSE, CentOS, and Ubuntu

Medium Security

This adds data encryption to Basic Security in order to secure the data should the system fall into untrusted hands. TrueCrypt and LUKS are solutions for Linux systems.

This is the main focus of our initial effort to comply with UAB Data Security Practices for laptops.

High Security

Not yet defined.

Some thoughts:

  • automatic login promises some intriguing usability scenarios that are common in distributed environments, so it might be interesting to explore how an unauthenticated local account might access machine resources but not provide automatic access to specific user accounts. Think about the analogy between using a browser to access the web but then gaining authorized access to key resources. There is typically no authentication assumed to access the web browser (eg. modern desktop).

Laptop Encryption

We use LUKS for file system encryption.

LUKS has many features including up to 8 passwords to unlock the encrypted drive. This supports multi-user laptops and key escrow. It's also possible to hook LUKS in with PAM and auto-mounting which promises some interesting scenarios. LUKS flexibility suggests many configuration options.

We are using two scenarios or our laptops:

  1. PGP-style whole disk encryption
  2. Mac FileVault-style /home partition encryption

Both seem to work well. Depending on your distro of choice they have varying degrees of support for LUKS:

  • Fedora9/nextgen-RHEL offer whole-disk encryption at install. Not sure if this includes swap. The Fedora integration is the nicest we've seen, primarily because it prompts the user with pretty GUI for their boot password. Look forward to seeing this style in the other distros. (The default LUKS prompt would be hard to call "intuitive".)
  • openSUSE 11.x offers /home disk encryption at install. This is the FileVault?-style scenario. I'm using that on my laptop. It works well. I have also configured my TMP environment variables to keep data out of /tmp and /var/tmp and in my $HOME. This has been effective so far at keeping all files under my $HOME after a couple of months of heavy use.
  • openSUSE 10+ offers documentation on how to build a whole-disk encrypted system in the course of a fresh install. We use this on one of our laptops. It has worked well too. There was an incident with suspend/resume recently but it's not clear if LUKS had anything to do with it. We didn't have resources to debug, so did a new install.
  • Ubuntu has similar docs to the one for openSUSE. Haven't tried it at all.

Any of these configurations could be applied to "existing" systems by simply backing up the /home dirs and doing an install with the encryption options. If you use tar or cpio to take an image /home, make sure you any really large files +8GB are backed-up before you delete your data. We ran into some limit of stuffing these large files into tar and cpio archives, not sure about the details.

Notes from the upgrade of a SUSE 10.2 laptop to openSUSE 11.1 provide some guidance on what's involved. The steps are essentially:

  1. Backup your $HOME
  2. Install Linux with encryption support
  3. Restore your $HOME
  4. (When using the FileVault-style scenario) Redefine your temporary files location to the encrypted partition

Exploring Tools and Distros

To prepare for the laptop encryption and develop a better understanding of the state of the art for encrypted drives on Linux we set up several VMs with different distros and followed the docs.