CAUTION:

This project is still in beta.  There are plenty of rough edges still
remaining.


SHORT DESCRIPTION OF THIS PROJECT:

The Enforcer is a Linux Security Module designed to improve integrity
of a computer running Linux by ensuring no tampering of the
file system.  It can interact with TCPA hardware to provide higher
levels of assurance for software and sensitive data.


LONGER DESCRIPTION OF THIS PROJECT (general announcement):

The Bear/Enforcer Project
Dartmouth College

http://enforcer.sourceforge.net
http://www.cs.dartmouth.edu/~sws/abstracts/mswm03.shtml

How can you verify that a remote computer is the "real thing, doing
the right thing?"  High-end secure coprocessors are expensive and
computationally limited; lower-end desktop enhancements like TCPA and
the former Palladium have been mainly limited to Windows and
proprietary development.

In contrast, this code is part of our ongoing effort to use open
source and TCPA to turn ordinary computers into "virtual" secure
coprocessors---more powerful but less secure than their high-assurance
cousins.

Our current beta release includes the Linux Enforcer Module, a TCPA
enabled LILO, and a user-level TCPA library.  All source is available
from the SourceForge site.

The Linux Enforcer Module is a Linux Security Module designed to help
improve integrity of a computer running Linux.  The Enforcer provides a
subset of Tripwire-like functionality.  It runs continuously and as
each protected file is opened its SHA1 is calculated and compared to a
previously stored value.

The Enforcer is designed to integrate with TCPA hardware to provide a
secure boot when booted with a TCPA enabled boot loader.  TCPA
hardware can protect secrets and other sensitive data (for example,
the secrets for an encrypted loopback file system) and bind those
secrets to specific software.

When the Enforcer detects a modified file it can, on a per-file basis,
do any combination of the following: deny access to that file, write an
entry in the system log, panic the system, or lock the TCPA hardware.
If the TCPA hardware is locked then a reboot with a un-hacked system is
required to obtain access to the protected secret.

We developed our own TCPA support library concurrently with, but
independently from, IBM's recently announced TCPA code.  Our library
was an initial component of the Enforcer project.  However, our
in-kernel TCPA support and the enforcer-seal tool are derived from
IBM's TCPA code because of its ease of adaptation for in-kernel use.
We plan to use our more complete library for user-level applications.
(IBM's TCPA code and documentation is available from
<http://www.research.ibm.com/gsal/tcpa/>.)

For more information on our project, see Dartmouth College Technical
Report TR2003-476 available from
<http://www.cs.dartmouth.edu/~sws/abstracts/mswm03.shtml>

You can contact Omen Wild for Enforcer questions:
<Omen.Wild@Alum.Dartmouth.ORG>

Or John Marchesini for TCPA questions:
<John.C.Marchesini@Dartmouth.EDU>

HOW IT WORKS:

The Enforcer is a Linux Security Module (LSM).  It taps the
inode_permission hook.  This hook is called every time a file is
opened for access.  The SHA1 of the file is calculated and compared
against a value stored in a configuration file.  If the values match,
then the contents of the file have not been tampered with and the open
succeeds.  If the SHA1 values do not match, then the Enforcer can do
any combination of the following (configurable on a per-file basis):
deny access, log an error, lock the TPM, call a user-space helper, or
panic the system.


TCPA INTERACTION:

If you have make it this far, we will assume you have a general
knowledge of TCPA, what it is, and why we might be using it.  For
general background see some of the papers linked off the IBM TCPA site
<http://www.research.ibm.com/gsal/tcpa/>.  The August 2003 edition of
the 'Linux Journal' has an excellent article from IBM's TCPA research
titled 'Take Control of TCPA', starting on page 50.

Our primary design goal is to protect the encryption key of an
encrypted loopback file system.  The Enforcer monitors the critical
system files, and when it detects tampering, denies further access to
the protected secret.


DOWNSIDE:

There is a fairly hefty memory requirement to store the database of
files and their SHA1s.  Currently each file takes about 40 bytes plus
the length of the full path of the file.  For 60,000 files that could
be as high as 20 megabytes.

There is a performance penalty as well.  The contents of every
protected file get SHA1'd every time they get loaded off of disk (see
the TODO about caching results).  The actual slowdown depends on your
workload.  Bottom line, if your CPU is close to maxed and you are
constantly loading protected files, you will probably have a problem.
For detailed benchmarks see the Dartmouth Tech Report
<http://www.cs.dartmouth.edu/~sws/abstracts/mswm03.shtml> or the
BENCHMARK file.


CAVEATS:

One of the PCRs that the Enforcer depends on is the MBR.  This block
gets written by lilo.  If you change ANY lilo options then the MBR
changes and you will not be able to get your secret out of the TPM.

The TPM module distributed with the Enforcer is not SMP compatible.
You will be unable to build with the Enforcer if SMP is enabled.


REPORTING BUGS:

If you find a bug, or have any comments/ideas, please report them via
the SourceForge bug tracking system
<http://sourceforge.net/tracker/?group_id=87771&atid=584320> so we can
fix them.


PROJECT HOME PAGE:
<http://enforcer.sourceforge.net/>