Shadow hardening

The shadow password mechanism was introduced to provide increased security over the early Unix practice of stored salted-and-hashed passwords in /etc/passwd — but that fact by no means makes it perfect. The Openwall security-hardened Linux distribution (better known as Owl) offers its own alternative called tcb, built around per-user directories and Blowfish encryption. Recently developer Paweł Hajdan unveiled a similar project of his own, which utilizes several of tcb's improvements, but supplies them in what Hajdan hopes is an easier-to-manage design.

Originally, /etc/passwd contained a hashed version of each account's password. The file itself was readable by any user, which enabled features like looking up usernames by their UIDs, and other tricks unrelated to the passwords themselves. The trouble was that attackers could calculate hashes offline then compare their results against /etc/passwd looking for matches. Shadow shuts down that attack vector by separating the hashed password information into a separate file that is readable only by trusted processes. In a sense, both tcb and hardened-shadow take that same approach: separating unrelated information further to reduce the potency of attacks.

Taking care of passwords

Openwall's tcb mechanism stores salted-and-hashed passwords in a directory of its own, /etc/tcb/, beneath which there is a separate directory for each user. Each user's directory is owned by that user account, and contains their own private shadow file (e.g., /etc/tcb/linus/shadow) also owned by the user.

Both the per-user directory and its contents are in the auth group with the SGID bit set for the directory, which provides for additional password policy enforcement. Namely, the system can grant a process read-only access to password hashes and the password-changing tools use each user's private directory as scratch space for the temporary and lock files required during the process. Openwall maintains that this set-up eliminates the need for SUID-root binaries altogether.

Apart from the system password-changing utilities, most application programs access shadow password hashes through either Pluggable Authentication Modules (PAM) or the Name Service Switch (NSS) facility. Tcb provides a custom PAM module named pam_tcb and a corresponding NSS module named libnss_tcb that supersede their /etc/shadow-based alternatives, such as the pam_unix module. As a result, migrating from a shadow system to tcb should be completely transparent to other applications. Openwall provides its own patched suite of shadow utilities (including login, useradd, chpasswd, newgrp, and so on) patched to support /etc/shadow in addition to /etc/tcb/*/shadow (configurable via a switch in /etc/login.defs), as well as utilities to convert from shadow to tcb and vice-versa.

But Owl's tcb scheme also involves a change to Glibc, so that the crypt(3) function uses the Blowfish cipher. The existing Glibc crypt() offers MD5, SHA-256, and SHA-512 encryption methods. The tcb version patches in Blowfish support that is "mostly compatible" with OpenBSD's bcrypt. The principle advantage is that Blowfish can be configured to use as many set-up rounds as desired when generating the hash; thus administrators can increase the number of rounds over time to make attacks more and more computationally expensive as processor power increases.

Hardened-shadow

Hajdan calls his package hardened-shadow, which he says is inspired directly by tcb. In a March 14 post to the owl-dev list, Hajdan asks for feedback from people interested in the project as well as help performing a security audit of the code.

Hardened-shadow is a reimplementation of the shadow utilities based on the original upstream sources, but supporting a somewhat tcb-like layout. The system uses /etc/hardened-shadow/, with a separate directory for each user account. But while tcb only stores a single shadow file for each account, hardened-shadow adds two more: a shell file and an aging file. The shell file allows chsh to modify the user account's default shell without having access to the shadow file, and aging holds the password expiration fields, which would eliminate the need for locking if administrators expired passwords before changing them, according to Hajdan.

In addition, hardened-shadow does not require a patched version of Glibc crypt(), and it supports more PAM options than does pam_tcb. Fans of the Blowfish algorithm might balk at the omission of their favorite cipher, but Hajdan has added a PAM parameter to pam_hardened_shadow that allows one to pass the hash algorithm as an argument. In the standard crypt() scheme, the hash algorithm used is designated by a token surrounded by $ characters — MD5 uses $1$, SHA-256 uses $5$, and so on. Hajdan believes making the PAM module indifferent to the hash algorithm makes the code more useful, so that Owl users can take advantage of Blowfish, while others can use their own cipher — and future-proofs it against new exploits that target particular ciphers.

On the down side, Hajdan admits that his code is currently incompatible with SELinux and with NIS. More importantly, of course, it is brand-new and virtually untested, so he advises against deploying it on any production systems.

Openwall's Alexander Peslyak (aka Solar Designer) offered several reasonable suggestions as feedback to Hajdan's list message. Among them were switching to a common open source license in place of Hajdan's current, custom license text, and building hardened-shadow around pam_tcb rather than implementing yet another PAM module with virtually the same goals. Hajdan's reply was that he felt pam_tcb's reliance on a patched Glibc made for too many packages, and that pam_tcb duplicated too many functions already found elsewhere in the tcb library.

Nevertheless, Peslyak said that Openwall would consider migrating to hardened-shadow's version of the shadow utilities (although not the PAM and NSS modules). The reason he gave was that Openwall currently maintains its patch set against a suite of tools that come from a blend of two different sources: the canonical shadow utilities, and a PAM-based implementation called SimplePAMApps. SimplePAMApps, however, is no longer being actively maintained. Owl and a few other distributions curate their own packages of it, but in the long run, synchronizing with an actively developed tool set is probably less work.

The shadowy future

Back in 2010, Hajdan submitted patches to the shadow utilities to enable optional support for tcb, a change that appears to have landed in the 4.1.5 release from February 2012. Nevertheless, tcb is still an essentially Owl-only tool. There does not seem to be much interest in packaging it among the large, "mainstream" distributions; in 2006 the idea was floated on the fedora-devel list where it was met with skepticism.

Some of the criticism from 2006 is questionable (for example, the concern that users could fill up the /etc filesystem by dumping files into their /tcb/ directories — the group permissions should prevent that), but others, such as requiring new methods for auditing password changes, may be more valid. Hardened-shadow does not alleviate all of those concerns, but by virtue of not requiring a patched Glibc, it at least stands a better chance of being packaged by other distributions.

Any hope for widespread deployment, however, will probably still need to address the SELinux incompatibility in the PAM module — and it will certainly need to wait for a proper security audit and more sets of eyes scrutinizing the code. Shadowed passwords were introduced to split up user account information in a manner that made security exploits harder. As both of these projects show, further division holds the possibility of protection against other attacks. Neither tcb nor hardened-shadow is a perfect solution, of course, but the existing shadow system is far from flawless, too, which is part of what makes a fresh re-examination of it such an interesting exercise.