Ensuring that a Linux system is only running "approved" programs—ones
that haven't been maliciously replaced—is one of the goals of the integrity patches currently
being proposed for the Linux mainline. With some hardware assistance, in
the form of a Trusted
Platform Module (TPM) chip, systems will be able to
protect against unauthorized binaries as well as attest to other systems
that they are only running good code. These patches have been around for a
number of years in various forms, but it would seem they are getting close
to being merged. Perhaps more interestingly, we are starting to see them
be used by various projects.
Over on the kernel page, we have looked at the integrity patches several
times, most recently in March
2007. The core idea is to complement mandatory access control (MAC)
systems, such as SELinux, by preventing attacks that are made when that
system isn't running—the machine has been booted with a different
kernel for example. It is generally considered a security truism that
physical access to a device moots any security measures, but with a
properly outfitted TPM-based system, that is no longer the case.
Conceptually, there are two parts to the integrity feature. One is the
extended verification module (EVM) that associates each file
with a hash that has been calculated over its contents and
metadata. That hash is then signed by the TPM chip ensuring that
unauthorized changes will be noticed.
The other half
is the integrity measurement
architecture (IMA) which tracks the use of mmap().
IMA verifies the hashes of files that have been mapped in
executable mode and then keeps track of them in a way that the TPM can
sign. EVM then provides the
protection against tampering with binaries, while IMA can provide a signed
attestation of which executables have been run.
Previous incarnations of EVM and IMA used the Linux Security Modules (LSM)
interface, but that has a very unfortunate side effect: inability to also
run SELinux. LSM code has no way to stack or cooperate, so there can only
be one module active at a time. Since integrity and MAC are intended to
work together, this was seen as a rather serious impediment, so the most
recent versions add in hooks for Linux Integrity Modules (LIM). IMA is
then added as a LIM integrity provider rather than as an LSM.
In response to an Andrew Morton query about the need for LIM/IMA (EVM has
been incorporated into IMA over time), David Safford listed several users of the code:
LIM/IMA's maintenance of a TPM hardware anchored file measurement
list is fundamental to the Trusted Computing Group's standards
efforts. Several projects have implemented the TNC (Trusted Network
Connect) and PTS (Platform Trust Services) standards (see below).
There are three demo packaged distros which have integrated these
apps, two of which are government funded (EU and US), with definite
customer interest. We are working with the RHEL team to provide
a supported, patched kernel for HAP. All of these so far have used
the old LSM based IMA, and have asked for a supported, upstreamed
implementation, with the ability to work with SELinux.
While that looks a bit like alphabet soup, there is a lot of useful
information there (and in his links further down in the post linked
above). The biggest news is the three distributions that are implementing
Assurance Platform (HAP) program is funded by the US National Security
Agency (NSA), the folks who brought us SELinux, while the Open Trusted Computing project is funded
by the European Commission.
While the security that can be provided by a Trusted Computing platform is
useful for some installations, there are some potential pitfalls as well.
Systems with TPM hardware can be configured to only run binaries that are
signed by some external authority. If manufacturers were to enable that
functionality, but only provide the key to "trusted" software companies,
it would lead to a horrendous loss of freedom. This is why some have
called it "Treacherous Computing".
There are numerous examples of systems that do not necessarily preserve
physical security, but that one might want to ensure were running the
proper code—voting and cash machines come quickly to mind. For those
situations, as well as countless others, Trusted Computing will be a real
boon. We just need to be vigilant so that hardware vendors (or, worse yet,
governments) don't start restricting what we can run on our own machines.
to post comments)