
             LOMAC - Low Water-Mark Mandatory Access Control

                          User's Manual v1.0.4

                            13 February 2001

   Tim Fraser
   tfraser@nai.com
   NAI Labs
   3060 Washington Road
   Glenwood, MD 21738-9745
   USA

   This is a revision of NAI Labs Technical Report Number 0766.

   Copyright (c) 1999, 2000, 2001 NAI Labs.  You may reproduce and
   distribute this document so long as this copyright statement and
   disclaimer are retained on all copies.  Although we have tried to
   be complete and correct, this manual is provided with NO WARRANTY.


[ Synopsis ]

This is the manual for LOMAC: a security enhancement for Linux that
used Low Water-Mark Mandatory Access Control to protect the integrity
of processes and data from viruses, Trojan horses, malicious remote
users, and compromised root daemons.  LOMAC is implemented as a
Loadable Kernel Module (an LKM, like a driver) - no kernel
recompilations or changes to existing applications are required.
Although some features and fixes remain to be implemented, LOMAC
presently provides sufficient protection to thwart "script kiddies",
and is now stable enough for everyday use.

LOMAC operates on single-CPU machines running Linux 2.2 kernels.
LOMAC is Free software available under the GNU GPL from
ftp://ftp.tislabs.com/pub/lomac.  It is not hard to experiment with
LOMAC: since LOMAC does not require the modification of existing
software or configuration files, installation is merely a matter of
copying files and running insmod to load the LKM.  De-installation
requires only deleting these files and rebooting.

[ Contents ]

   1.  Introduction
   2.  Installation
   3.  A Short Tour
   4.  De-installation
   5.  LOMAC and Network Servers
   6.  LOMAC and Traditional UNIX Access Control
   7.  Limits to LOMAC's Protection
   8.  Installing New Software
   9.  Performance
   10. Related Projects



[ 1.  Introduction ]

Several projects have demonstrated that kernel-resident Mandatory
Access Control (MAC) mechanisms can protect the integrity of Free UNIX
systems from malicious code and users.  However, implementations of
these mechanisms have traditionally required invasive kernel
modifications, sometimes coupled with supporting modifications of
user-space utilities, as well.  This requirement has hindered the
adoption of MAC mechanisms in the mainstream Free UNIX community.
Adoption has been further discouraged by the difficulty of starting
small and evolving towards a complete MAC solution - in general, the
complete set of extensive modifications must be made before MAC can
provide any useful protection.

LOMAC is an attempt to make an easily-adoptable form of MAC integrity
protection available to the Free UNIX community without the
discouraging necessity of kernel modifications.  LOMAC implements a
simple form of MAC integrity protection based on Biba's Low Water-Mark
model in a Linux Loadable Kernel Module (LKM) [BIB77, FRA00].
Although it trades off some of the advanced MAC features found in
traditional MAC implementations, LOMAC provides useful integrity
protection without any modifications to the kernel, applications, or
their existing configurations.  LOMAC is designed to be compatible
with existing software, and ships with a one-size-fits-all default
configuration.  LOMAC may be used to harden currently-deployed Linux
systems simply by loading the LKM into the kernel shortly after boot
time.

Once loaded, LOMAC divides the system into two conceptual levels of
integrity: high and low.  The high side contains all process and files
that should be protected from malicious code and remote users: the
kernel servers (kflushd and friends), the system binaries (bin, lib),
the system configuration files (etc), and any mission-critical data
(your web pages).  The low side contains the processes that interact
with remote users (remote login sessions, httpd) and the files they
download from the net (mail attachments).  Low files may contain
viruses or Trojan Horses.  Low processes take input from remote users
that may cause buffer overflows.  During run-time, LOMAC protects high
files and processes by preventing low processes from modifying or
signalling them.  Thanks to is generic default configuration, LOMAC
handles the division of the system into high and low parts
automatically, without administrative direction.

LOMAC does not override the existing Linux protection mechanisms.
Instead, its permission checks are done in addition to the existing
ones - the kernel permits an operation only if both the existing
mechanisms and LOMAC decide it should permit it.  Unlike the existing
Linux protection mechanisms, LOMAC makes decisions based solely on
integrity level, not on user identity.  With LOMAC, a low-level root
process is just as powerless as a low-level non-root process.  Since
LOMAC automatically places all network servers in the low part of the
system, this fact prevents compromised root-privileged network servers
from harming the high-integrity part of the system.

This document is the manual for LOMAC.  It is intended both for those
who wish to understand and improve the LOMAC software, and for those
who simply wish to use LOMAC.  Other documents concerning lomac can be
downloaded from ftp://ftp.tislabs.com/pub/lomac.  This FTP site also
contains the archive for the lomac-users mailing list, in the
lomac-users-archive subdirectory.  The lomac-users mailing list is the
primary public forum for discussing LOMAC, and all persons interested
in learning about, using, or improving LOMAC are welcome to join.  To
join the lomac-users mailing list, send mail to

    <Majordomo@lists.tislabs.com>

with the following command in the body of the message:

    subscribe lomac-users



[ 2.  Installation ]

LOMAC is Free software.  You can download LOMAC and use it under the
terms of the GNU General Public License (GPL).  LOMAC distributions
are available at ftp://ftp.tislabs.com/pub/lomac .  A copy of the GPL
is included in the distribution.

LOMAC operates on single-CPU machines running Linux 2.2 kernels.
Since LOMAC does not require the modification of existing software or
configuration files, installation is merely a matter of copying files
and running insmod to load the LKM.  De-installation requires only
deleting these files and rebooting.  Consequently, potential users may
install LOMAC, try it out, and (if they so choose) easily de-install
it, leaving their system as it was before.

The LOMAC install procedure has not yet been automated.  To install
LOMAC, you must perform the following steps manually.

1.  If you have not done so already, download the latest LOMAC
    distribution from: ftp://ftp.tislabs.com/pub/lomac.  

2.  gunzip and tar -xf the distribution file.  This should create a
    "Lomac" directory.  You may wish to browse the contents of this
    directory and read the README files, as they may be more
    up-to-date than this manual.  You should also read the BUGS file,
    as this file may describe workarounds for bugs and deficiencies
    currently in LOMAC.

3.  cd Lomac/Src/LKM

4.  make clean ; make

5.  cd Lomac/Src/Lup

6.  make clean ; make

7.  su

8.  mkdir -p /opt/lomac/bin

9.  cp Lomac/Src/Lup/lup /opt/lomac/bin

10.  cp Lomac/Src/LKM/lomac_mod.o /opt/lomac/bin

11.  cp Lomac/Src/Scripts/l* /opt/lomac/bin

12.  cp Lomac/Src/Scripts/startLomac /opt/lomac/bin

13.  mv /opt/lomac/bin/lomac /etc/rc.d/init.d 
     In some Linux distributions, you may find /etc/init.d instead of
     /etc/rc.d/init.d.

     The lomac file is LOMAC's System-V-style init script.  If your
     system uses a BSD-style init (that is, if you have one big rc
     script instead of separate directories for different
     "runlevels"), you may simply add a line to execute
     /opt/lomac/bin/startLomac from your rc script.  You should start
     LOMAC after the filesystems have been mounted, but before the
     network comes up.

     At this point, /opt/lomac/bin should look something like this:

> ls -l /opt/lomac/bin/
total 82
-r-xr-xr-x   1 root     root         1968 Oct 24 18:36 level
-r-xr-xr-x   1 root     root         2238 Oct 24 18:36 linfo
-r-xr-xr-x   1 root     root         4272 Oct 24 18:36 lls
-rw-r--r--   1 root     root         7503 Oct 24 18:36 lomac.pm
-rw-------   1 root     root        42059 Oct 15 05:31 lomac_mod.o
-r-xr-xr-x   1 root     root         3964 Oct 24 18:36 lps
-rwxr-xr-x   1 root     root        13790 Sep  7 11:14 lup
-r-xr-xr-x   1 root     root         1714 Nov 26  1998 startLOMAC

14.  /sbin/chkconfig --add lomac

     If your system uses a BSD-style init, you should skip this step.

     chkconfig is a program included with some Linux distributions to
     automatically set up the proper S and K symbolic links from the
     various rc?.d directories to init.d/lomac.  If you do not have
     chkconfig, you should manually set up the symbolic links to start
     LOMAC first and kill LOMAC last in runlevels 2, 3, 4, and 5.

     At this point, LOMAC should be set to run:

> /sbin/chkconfig --list | grep lomac
lomac 0:off 1:off 2:on 3:on 4:on 5:on 6:off

     LOMAC is not set to run in single-user mode.  If LOMAC gives you
     trouble, you can always reboot to single user mode ("linux single"
     at the bootloader prompt), turn LOMAC off, and proceed to a
     higher runlevel ("/sbin/init 3" or "/sbin/init 5" if you run XDM).

15.  Optionally, you may also install the suite of test scripts
     included in the distribution:

     mkdir /root/Test
     cp Lomac/Src/Test/Lomac/* /root/Test

     These scripts test many of LOMAC's major features.

16.  Reboot.  Proceed to runlevel 3, 4, or 5.


[ 3.  A Short Tour ]

This section introduces LOMAC's major features.  You may follow these
steps the first time you boot with LOMAC running to ensure that your
installation is correct.  LOMAC is sensitive to the location of
certain files.  Since different Linux distributions sometimes place
certain files in different locations, LOMAC may not have installed
correctly on your system even though you followed the above
installation instructions exactly.  These problems have not proven
difficult to fix in the past.  If you experience trouble, please join
the lomac-users mailing list (see the introduction) and describe your
symptoms.

  1.  Log in as root, from the system console (not from X).

  2.  Check to make sure that the LOMAC LKM is loaded:
      # /sbin/lsmod | grep lomac
      lomac_mod              30984   0  (unused)

  3.  Look at the levels of your processes:

      # /opt/lomac/bin/lps
      PID LVL TTY          TIME CMD
      842   2 tty1     00:00:00 login
      854   2 tty1     00:00:00 tcsh
      873   2 tty1     00:00:00 lps
      875   2 tty1     00:00:00 ps

      Note that all your processes are running at level 2 - LOMAC's
      highest level of privilege.  

  4.  Look at the levels of your files:

      # /opt/lomac/bin/lls
      drwxr-x---   root        root          2   .
      drwxr-xr-x   root        root          2   ..
      -rw-r--r--   root        root          2   .bash_history
      -rw-r--r--   root        root          2   .bash_logout
      -rw-r--r--   root        root          2   .bash_profile
      -rw-r--r--   root        root          2   .bashrc
      drwxr-xr-x   root        root          2   Test

      Note that all your files are also at level 2.  Level-2 files are
      high-integrity - LOMAC assumes that they contain no viruses or
      Trojan horses at boot time, and limits the behavior of processes
      during run-time to keep them that way.

  5.  Look at the levels of a normal user's files.  I'll use the user
      tfraser in the example; you'll have to use one of your own users.

      # /opt/lomac/bin/lls /home/tfraser
      drwx------   tfraser     tfraser       1   .
      drwxr-xr-x   root        root          2   ..
      -rw-r--r--   tfraser     tfraser       1   .cshrc
      -rw-r--r--   tfraser     tfraser       1   .login
      drwx------   tfraser     tfraser       1   .netscape
      drwxrwxr-x   tfraser     tfraser       1   Hunt
      drwxrwxr-x   tfraser     tfraser       1   Projects
      drwxrwxr-x   tfraser     tfraser       1   Satan

      Note that while /home is level 2 (high integrity), all of the
      user's files are level 1 (low integrity).  LOMAC assumes that
      any of the user's files may be Trojan horses or contain viruses.
      This includes files downloaded from the Internet - note the
      level-1 .netscape directory.

  6.  Examine one of the user's files with less, and put less in the
      background with ctrl-Z.  Then run lps to look at your processes.

      # less /home/tfraser/.cshrc
      <output not included in document to save space>
      ^Z
      Suspended
      # /opt/lomac/bin/lps
       PID LVL TTY          TIME CMD
      1200   2 tty1     00:00:00 login
      1217   2 tty1     00:00:00 tcsh
      1417   1 tty1     00:00:00 less
      1431   2 tty1     00:00:00 lps
      1433   2 tty1     00:00:00 ps

      Note that, although your shell (tcsh in my case) is still at
      level 2, the process running less is at level 1.  Here's why:
      Processes generally inherit the level of their parent.  So, any
      process you start with your level-2 shell will initially execute
      at level 2.  The less process was no exception - it began
      running at level 2.  However, the less process went on to read
      the user's .cshrc file.  This file is a level-1 file - it
      contains low-integrity data.  Whenever LOMAC sees a level-2
      process read a level-1 file, LOMAC "demotes" the process.  That
      is, it reduces the process to level 1.

      Level-2 processes have maximum privileges (like "root" in
      standard UNIX).  Level-1 processes have greatly reduced
      privileges.  For example, they cannot write to level-2 files, or
      signal level-2 processes.  When a level-2 process reads a
      level-1 file, it puts itself at risk.  The file may be a Trojan
      horse or may contain data designed to cause buffer overflows.
      Because of this risk, LOMAC demotes level-2 processes that read
      level-1 files to level 1.  Once at level 1, these processes have
      insufficient privilege to harm level-2 processes and files.

      Many cautious UNIX administrators avoid putting "." in their
      PATH environment variable, in order to avoid executing some
      Trojan horses.  In standard UNIX, a malicious user might give an
      attack program the same name as a commonly-used command like
      "ls".  If the administrator, running as root, were to cd to the
      malicious user's directory and type "ls", if the "." preceded
      "/bin" in their path, they would accidentally execute the
      malicious ls rather than /bin/ls.  This act would effectively
      execute the malicious user's Trojan horse program with root
      privileges, perhaps to modify the login program or the passwd
      file.

      This precaution is not required in a system running LOMAC.
      LOMAC considers the execution of a program to be equivalent to a
      read (since the process reads the program file in order to
      execute it).  Since all non-root user's files are at level 1,
      LOMAC would demote the process executing the Trojan ls, just as
      it demoted less in our example, above.  Once at level 1, LOMAC
      would prevent the Trojan ls from modifying level-2 files such as
      the login program or the passwd file.

      Demotion is a key part of the LOMAC's integrity protection
      scheme.  Now that we've demonstrated how it works, we're now
      done with less.  Quit the less program.

      # fg
      <output not included in document to save space>
      q

  6.  Create a test file.  We'll use this test file to demonstrate LOMAC's
      integrity protection later on.

      # cat > /root/foo
      This file contains test data.
      ^D

  7.  tail -f /var/log/messages

      Leave this running while you continue the tour.  It's output will
      contain LOMAC log messages as we proceed.

  8.  Switch to another virtual console (perhaps by hitting ALT-F2)
      and log in as a normal user.  Once logged in, examine the levels
      of your processes:

      [dyn65:~ ] /opt/lomac/bin/lps
        PID LVL TTY          TIME CMD
       1452   1 tty2     00:00:00 tcsh
       1472   1 tty2     00:00:00 lps
       1474   1 tty2     00:00:00 ps

      Note that as a normal user, all of your processes are at level 1.
      Why?  Switch back to the virtual console where you are logged in
      as root (perhaps by hitting ALT-F1).  You should see a log
      message similar to:

      Dec 20 13:23:35 (none) kernel: LOMAC: level-2 subject
      p1452g1452u500:tcsh demoted to level 1 after reading
      /home/tfraser/.cshrc

      All the getty programs that handle logins run at level 2.  When
      a user attempts to log in, they run the login program, which
      also runs at level 2.  Upon supplying the proper password, the
      login program starts a shell for the user (tcsh in this case).
      The shell starts at level 2, but LOMAC demotes it to level 1
      when it reads the user's .cshrc file, just as it demoted the
      less program, above.  Once the user's shell is running at level
      1, all of the programs subsequently executed by the user will
      run at level 1, also.

      Our root shell from the start of the tour remains at level-2
      because LOMAC has set all of root's files at level 2.  A level-2
      process may read level-2 files without being demoted.  The
      user's shell is demoted because it reads the user's level-1
      files.  LOMAC does not assign levels to processes based on the
      user's root/non-root identity.  LOMAC assigns levels to files by
      starting the first process (/sbin/init) at level 2, allowing
      child processes to inherit their parent's level, and by demoting
      processes that read level-1 files.  LOMAC does not pay any
      attention to user identity.  Consequently, LOMAC is not
      vulnerable to any of the traditional attacks on UNIX security
      that involve obtaining root identity.

  9.  Test the above assertion that LOMAC does not give any extra
      privileges to processes with root identity.  Switch back to the
      normal user's shell and become root.

      [dyn65:~] su
      Password: 
      [tfraser@dyn65 tfraser]# lps
      PID LVL TTY          TIME CMD
      1486   1 pts/1    00:00:00 login
      1498   1 pts/1    00:00:00 su
      1500   1 pts/1    00:00:00 tcsh
      1703   1 pts/1    00:00:00 lps
      1705   1 pts/1    00:00:00 ps

      Note that, despite the su, your shell is still at level 1.
      LOMAC never increases the level of a process.  Now attempt to
      delete the /root/foo file you created earlier.

      [tfraser@dyn65 tfraser]# /opt/lomac/bin/lls /root
      drwxr-x---   root        root          2   .
      drwxr-xr-x   root        root          2   ..
      -rw-r--r--   root        root          2   .bash_history
      -rw-r--r--   root        root          2   .bash_logout
      -rw-r--r--   root        root          2   .bash_profile
      -rw-r--r--   root        root          2   .bashrc
      drwxr-xr-x   root        root          2   Tmp
      -rw-r--r--   root        root          2   foo
      [tfraser@dyn65 tfraser]# rm /root/foo
      rm: remove `/root/foo'? y
      rm: cannot unlink `/root/foo': Operation not permitted

      Even though you are root, LOMAC will not allow a level-1 process
      (rm in this case) to delete a level-2 file.  You should see a
      log message similar to this one in on the root virtual console
      that is tailing /var/log/messages:

      Dec 20 13:41:22 (none) kernel: LOMAC: p1716g1716u0:rm level 1
      denied creat/trunc of /root/foo level 2

      This concludes your tour of LOMAC!  Congratulations, you are now a
      LOMAC user.  Please join the lomac-users mailing list.


[ 4.  De-installation ]

The following steps will de-install LOMAC, leaving the system as it was
before installation.

  1.  Log in as root on a virtual console (no X).  

  2.  Verify that you have a level-2 shell using lps, as described in
      the tour, above.  If you cannot get a level-2 root shell, you
      can also perform the following steps after rebooting to
      single-user mode.

  3.  /sbin/chkconfig --del lomac

      This will remove all of the S and K symbolic links to the lomac
      script in init.d.  If your system does not have chkconfig, you
      will have to remove these links manually.  If your system uses a
      BSD-style init, remove the call to /opt/lomac/bin/startLOMAC
      from your rc script.

  4.  rm /etc/init.d/lomac
      rm -rf /opt/lomac

  5.  If you installed the optional test programs, 
      rm -rf /root/Test

  6.  reboot.  You must reboot to remove the LOMAC LKM from the running
      kernel.  The LOMAC LKM cannot be removed by rmmod.


[ 5.  LOMAC and Network Servers ]

This section explains how LOMAC uses its demotion behavior to ensure
that all remote users and servers that serve remote users (httpd,
ftpd, etc.) run at level 1.  At this level, malicious remote users and
compromised network servers can do little harm to the level-2 part of
the system, even if they have root privilege.  It also discusses a few
of the finer points concerning LOMAC's protection scheme not already
covered in the "Short Tour" section, above.  The basic elements of
LOMAC's integrity protection scheme are summarized here:

  1.  LOMAC assigns every process, or named filesystem object (file,
      named pipe, or bound UNIX-domain socket) a level: either 1 (low
      integrity) or 2 (high integrity).
  2.  LOMAC assigns levels to filesystem objects based on their
      location in the filesystem namespace.  The mapping between names
      and levels constitutes most of LOMAC's "default policy", and is
      presently hard-coded into the LKM.  Once assigned, the levels of
      filesystem objects never change.
  3.  The first process (/sbin/init) starts at level 2.  All child
      processes inherit the level of their parent.  Only when a
      level-2 process reads from a level-1 object does LOMAC demote
      the process to level 1.
  4.  Level-1 processes have insufficient privilege to write to
      level-2 objects or signal level-2 processes.  This protects the
      level-2 part of the system from malicious interference.
  5.  The combination of LOMAC's demotion behavior and its
      restrictions on the privileges of level-1 processes prevent
      malicious level-1 users from harming the level-2 part of the
      system, even in cases where level-2 administrators accidentally
      execute malicious user's Trojan horses.

In UNIX, network servers are generally started automatically by the
init process, or by one of its children.  With LOMAC, this arrangement
guarantees that network servers inherit the init process's level of 2.
In addition to demoting level-2 processes upon reading level-1 files,
LOMAC also demotes level-2 processes when they read from a network
interface.  Consequently, LOMAC demotes network server as soon as they
read their first client request from the network.  Just as LOMAC
assigns appropriate levels to user shells based on their file-reading
behavior, not their user's identity, this scheme allows LOMAC to
demote network servers without initially knowing which programs are
network servers: LOMAC simply allows the init program to start all of
its servers at level 2, and subsequently demotes those servers which
read from a network interface.  

LOMAC uses the same strategy to ensure that remote users run at level
1: it demotes the remote login (TELNET, SSH) servers when they receive
their first login request, as described above.  LOMAC's ability to
automatically determine the proper levels for users and servers during
run-time is the feature which allows it to avoid site-specific
configuration and ship with a one-size-fits-all default policy.

Here is an example of an httpd server before it reads its first
request.  Note that the httpd server is comprised of 11 processes, all
at level 2.

# /opt/lomac/bin/lps ajx | grep 'PGID\|httpd'
 PPID   PID LVL  PGID   SID TTY      TPGID STAT   UID   TIME COMMAND
    1   355   2   355   355 ?           -1 S        0   0:00 httpd
  355   371   2   355   355 ?           -1 S       99   0:00 httpd
  355   372   2   355   355 ?           -1 S       99   0:00 httpd
  355   373   2   355   355 ?           -1 S       99   0:00 httpd
  355   374   2   355   355 ?           -1 S       99   0:00 httpd
  355   375   2   355   355 ?           -1 S       99   0:00 httpd
  355   376   2   355   355 ?           -1 S       99   0:00 httpd
  355   377   2   355   355 ?           -1 S       99   0:00 httpd
  355   378   2   355   355 ?           -1 S       99   0:00 httpd
  355   379   2   355   355 ?           -1 S       99   0:00 httpd
  355   380   2   355   355 ?           -1 S       99   0:00 httpd
  447   532   2   531   439 tty1       531 S        0   0:00 grep PGID\|httpd

After httpd reads its first request from the network, you should see a
message similar to this one in /var/log/messages:

   Dec 30 15:38:22 (none) kernel: LOMAC: level-2 subject
   p371g355u99:httpd demoted to level 1 after reading from the network

And running lps again will produce:

# /opt/lomac/bin/lps ajx | grep 'PGID\|httpd'
 PPID   PID LVL  PGID   SID TTY      TPGID STAT   UID   TIME COMMAND
    1   355   1   355   355 ?           -1 S        0   0:00 httpd
  355   371   1   355   355 ?           -1 S       99   0:00 httpd
  355   372   1   355   355 ?           -1 S       99   0:00 httpd
  355   373   1   355   355 ?           -1 S       99   0:00 httpd
  355   374   1   355   355 ?           -1 S       99   0:00 httpd
  355   375   1   355   355 ?           -1 S       99   0:00 httpd
  355   376   1   355   355 ?           -1 S       99   0:00 httpd
  355   377   1   355   355 ?           -1 S       99   0:00 httpd
  355   378   1   355   355 ?           -1 S       99   0:00 httpd
  355   379   1   355   355 ?           -1 S       99   0:00 httpd
  355   380   1   355   355 ?           -1 S       99   0:00 httpd
  447   610   2   609   439 tty1       609 S        0   0:00 grep PGID\|httpd

Note that LOMAC has demoted all 11 httpd server processes to level 1.
LOMAC considers all of the processes in a given process group (or
"job") to be a unit.  It keeps them at the same level at all times.
When one process in a process group triggers a demotion, LOMAC demotes
all of the processes in the group.  All 11 processes are in process
group number 355, so LOMAC has demoted them all.

The v0.2 version of the LOMAC prototype required this process group
behavior in order to properly control the use of unnamed pipes (as
described in [FRA00]).  Although the v0.3 and later prototypes'
unnamed pipe controls no longer require LOMAC to treat process groups
as a unit, LOMAC still retains this behavior.


[ 6.  LOMAC and Traditional UNIX Access Control ]

LOMAC does not override the existing Linux protection mechanisms.
Instead, its permission checks are done in addition to the existing
ones - the kernel permits an operation only if both the existing
mechanisms and LOMAC decide the kernel should permit it.

There are three main differences between the integrity protection
scheme implemented by LOMAC and traditional UNIX security mechanisms:

  1.  Traditional UNIX provides mechanisms by which processes can
      increase their privileges by changing their effective
      identities.  Although UNIX systems can be configured to prevent
      malicious users from exploiting these mechanisms in most cases,
      they can also be misconfigured, and good configurations can be
      foiled by bugs in user-space application programs.  LOMAC
      provides no mechanism to allow a process to increase its level.

  2.  Traditional UNIX access control mechanisms are not designed to
      prevent the flow of potentially dangerous data from
      low-integrity objects to high-integrity objects.  That is, from
      files owned by one user to those owned by another - even to
      those owned by root.  The Trojan ls scenario in the "Short Tour"
      section describes one well-known example of this vulnerability,
      and how LOMAC counters it.

  3.  Although many enhancements now exist, in its most basic form
      traditional UNIX depends on easily defeated authentication
      mechanisms to establish appropriate initial privilege levels.
      LOMAC assigns privilege levels to processes based on their
      reading behavior.  As described above, the effect of LOMAC's
      policy is to give the highest level of privilege only local
      administrative users, and the lowest level of privilege to all
      others, regardless of identity.  LOMAC does not consider user
      identity; consequently, it does not depend on authentication.


[ 7.  Limits to LOMAC's Protection ]

LOMAC embodies a trade-off between quality of MAC protection and
compatibility.  LOMAC's primary goal is to remain compatible with
existing software while providing some useful MAC integrity
protection.  The Low Water-Mark MAC model supports this
compatibility-first requirement.  However, it the quality of
protection it provides is not as great as that provided by more
modern, less compatible, models.  This issue is discussed at length in
[FRA00].  This section presents the two well-known primary
quality-of-protection drawbacks of the Low Water-Mark model: its
enforcement of the principle of least privilege, and its reliance on
trusted applications.

The first drawback of the Low Water-Mark MAC scheme concerns the
Principle of Least Privilege, which holds that a *good* MAC scheme
should grant a subject the minimum set of privileges needed to do its
job [SAL75].  Constraining a subject in this way minimizes the amount
of damage the subject can cause should it become compromised.  Low
Water-Mark provides weaker constraints than some more modern models.
The "LOMAC and Network Servers" section describes how LOMAC protects
the level-2 part of the system by demoting network servers to level 1.
Although LOMAC will prevent a compromised level-1 network server from
harming the level-2 part of the system, LOMAC will not prevent such a
server from doing harm in the level-1 remainder of the system.  A
compromised root-privileged network server could, for example, send
kill signals to another level-1 server.

The second drawback of the Low Water-Mark MAC scheme is its reliance
on trusted applications.  This reliance is a feature of hierarchical
models like Low Water-Mark [BOE85].  It can be best demonstrated by a
concrete example:

Linux has a system log file, /var/log/messages, maintained by a system
log daemon, syslogd, that reads log requests from a system log socket,
/dev/log.  Level-1 processes must be allowed to write to /dev/log, in
order to provide an audit trail of their (possibly malicious)
activities.  Consequently, LOMAC's default policy assigns level 1 to
/dev/log.  Given the description of LOMAC's behavior presented so far,
it would be reasonable to expect LOMAC to demote syslogd to level 1
upon reading its first log request from the level-1 /dev/log socket.
If syslogd is running at level 1, then the /var/log/messages must also
be at level 1 in order to allow syslogd to deposit its log messages.

However, this scenario presents a practical problem.  Malicious users
often seek to erase incriminating audit trails from the system log
object in order to cover their tracks.  In order to prevent this
erasure, LOMAC must assign level 2 to /var/log/messages.  But this
would raise its own problem: a level-1 syslogd cannot write to a
level-2 /var/log/messages.  The conflicting requirements for a log
/dev/log and a high /var/log/messages seem irreconcilable.

LOMAC solves this problem by adding the system log daemon, syslogd, to
its list of "trusted" programs.  A process that runs a trusted program
gains no extra privileges, except that LOMAC will never demote it,
regardless of what it reads.  This exception allows a level-2 syslogd
to read a level-1 /dev/log without being demoted, thereby enabling it
to subsequently write to a level-2 /var/log/messages.

The word "trusted" is meant to describe programs that have been
formally verified, providing some assurance that they will not abuse
their additional privileges.  Unfortunately, no such argument exists
for Linux's syslogd.  If a malicious user found some way to compromise
syslogd, perhaps by exploiting a buffer overflow or some other bug,
they might gain control of a level-2 process - the LOMAC equivalent of
gaining "root" privilege in a traditional UNIX system.  Because of
this danger, and the difficulty of producing formally verified trusted
programs, it is important to minimize the use of trusted programs.
LOMAC's default policy considers the following programs to be trusted:

  syslogd  /* the main system log daemon */
  minilogd /* a log daemon for early runlevels */
  mount    /* so we can mount NFS despite the required net read */
  cardmgr  /* avoid tmp-related demotion for pump */
  pump     /* pump is client-side DHCP agent, must read net and write /etc */
  lup      /* LOMAC's trusted upgrade program */

The security of a LOMAC system can be improved by running as few of
these programs as possible.  The latest list of trusted programs can
be found in lomac_tpl.c .

The last program in the list is "lup", LOMAC's trusted upgrader.  The
lup program permits a level-2 user to "upgrade" a level-1 file, that
is, to copy the data contained in a level-1 file into /root/upgraded,
which is a level-2 file.  The lup program must be run at level 2,
because although trust allows lup to avoid demotion, but it would not
allow a level-1 lup to increase its level to 2.  Only one file may be
upgraded at a time.  Upgraded files are always named /root/upgraded.
Each use of lup is logged to /var/log/secure.



[ 8.  Installing New Software ]

In some cases, LOMAC's integrity protection mechanism will require you
to use the lup program before installing new software packages.  LOMAC
does not interfere with the installation of new software packages from
CD-ROM, because the directory /mnt/cdrom is at level 2, as will be any
software package collections mounted under it.

However, LOMAC will force you to save software packages downloaded
from the network to level-1 files.  Installing level-1 software
packages may or may not require the use of the lup program, depending
on where you ultimately want to install the binaries.  There are two
cases:

  1.  LOMAC will not interfere if you want to install under
      /usr/local, /home, or in some other level-1 area of the
      filesystem; you will not need to use lup in those cases.

  2.  However, if you ultimately want to install the binaries in a
      level-2 area of the filesystem (/bin, /sbin, /lib, all of /usr
      except for /usr/local), you will need to lup the software
      package to a level-2 file before installing.

The level of any file in the filesystem can be determined by
consulting the following table.  Given a target pathname, search
through the table, from top to bottom.  When you find a table entry
with a pathname that is a prefix of your target pathname, the level of
a file named by your target pathname is that table entry's level.
There is one exception to this rule: if your target pathname matches
an entry pathname exactly, and the entry has a "children of" modifier,
ignore the match and move on to the next table entry.

    Modifier    Pathname               level
    ----------  ---------------------  -----
                /var/run/ftp.pids-all    1
                /var/log/messages        2
                /var/log/lastlog         2
                /var/log/secure          2
                /dev/printer             1
                /var/lib/nfs             2
                /var/lib/rpm             2
                /home/httpd              2
                /mnt/floppy              2
                /home/samba              2
                /mnt/cdrom               2
    children of /usr/local               1
                /home/ftp                2
                /dev/log                 1
    children of /usr/src                 1
    children of /usr/tmp                 1
    children of /var/lib                 1
                /var/lib                 2
    children of /var/log                 1
                /var/log                 2
                /var/run                 2
    children of /home                    1
    children of /mnt                     1
    children of /tmp                     1
    children of /var                     1
                /                        2

For example, /home/tfraser is level 1, due to the table entry for
/home.  /home, however, is level 2, due to the entry for /.  This
mapping between filenames and levels, coupled with the list of trusted
programs, effectively describes LOMAC's default policy.  The latest
mapping of filenames to levels is encoded in lomac_plm.c .



[ 9.  Performance ]

This section discusses the results of two performance benchmarks run
on LOMAC v0.3 with the path "/usr/src" added to its path-level map in
lomac_plm.c.  (The v0.3 LKM lacked this path, and /usr/local.  Other
than its version number, it is otherwise identical to the v1.0 LKM.)

The first benchmark involved measuring the time taken to complete a
"make" of the Linux kernel source on a system running the Linux 2.2.12
kernel as configured by the RedHat 6.1 distribution.  During the
tests, crond and atd were disabled, the network was physically
disconnected, and the mouse was overturned.  The hardware was an Intel
Pentium II 450MHz with 256 MB of RAM.  At no point during testing did
the CPU utilization exceed 63%.  "make clean" was executed between
runs of "make" timed with /usr/bin/time.  The results of the first run
in each configuration (LOMAC, non-LOMAC) were discarded to avoid
inconsistencies introduced by the filesystem cache.

                 Kernel build (make only)
      WITHOUT LOMAC                    WITH LOMAC
  trial     elapsed time (s)     trial     elapsed time (s)
    1       442.16                 1       444.35 
    2       442.21                 2       444.35
    3       442.15                 3       444.42
    4       442.18                 4       444.36
    5       442.19                 5       444.38
  average:  442.18               average:  444.37
  stddev:     0.02               stddev:     0.03

The percentage difference is near one-half of a percent in favor of
WITHOUT LOMAC - a good result.  However, building the kernel requires
a considerable amount of computation and a relatively small amount of
I/O.  Since LOMAC slows the I/O and not the computation, any
performance penalty introduced by LOMAC is heavily de-emphasized by
this benchmark.

The second benchmark involved measuring the maximum rate at which an
HTTP server could reply to requests for its root page running WITH and
WITHOUT LOMAC.  The HTTP client machine had hardware identical to the
test machine in the previous benchmark, and was running a Linux 2.2.5
as configured by the RedHat 6.0 distribution.  It used httpef-0.8 to
generate HTTP requests.  The server machine had an Intel Pentium
100MHz with 64MB RAM running Linux 2.2.12 as configured by the default
"server" install of the RedHat 6.1 distribution.  The HTTP server was
Apache/1.3.9 (Unix) (Red Hat/Linux).  It served the small default root
web page provided with the distribution.  The client and server
machines were directly connected via a crossover Ethernet cable.  Both
machines had 10BaseT Ethernet cards.

For each trial, httperf made 100000 requests with timeouts of 5
seconds.  Trials were made at various request rates until the rate
which produced the maximum average (that is, average over the duration
of the trial) server reply rate was found.

  average    average
  client     server
  request/s  replies/s  sttdev  timeouts
  ---------  ---------  ------  --------
          WITHOUT LOMAC
  133        133.0       1.7        0
  134        134.0       1.6        0     << maximum 134 server replies/s
  135         89.2      18.6    33733
  
           WITH LOMAC
  126        126.0       2.4        0
  127        127.0       1.9        0     << maximum 127 server replies/s
  128         95.6      18.9    24811

This resulted in an approximately 5% advantage for WITHOUT LOMAC.
This is a much more difficult benchmark that the first, since the
trials are almost entirely small I/O requests without computation -
read a request from the network, read the file from the filesystem,
write the file to the network.  Consequently, this benchmark might be
close to a worst-case analysis of LOMAC's performance penalty on
realistic workloads.


[ 10.  Related Projects ]

This section compares LOMAC with a number of other projects that are
concerned (at least in part) with adding MAC to open-source UNIX-like
operating systems.  The comparisons focus on each project's ability to
support MAC-based integrity protection, and the cost of this
protection in terms of compatibility with existing software,
configurations, and operational practices.

The projects discussed below demonstrate two strategies for providing
integrity protection with MAC.  LOMAC provides an example of the first
strategy by conceptually dividing the entire system into a series of
integrity levels and enforcing rules to ensure that potentially
corrupting data cannot move from low-integrity levels to
high-integrity levels.  As described in section 3, this
"ordered-levels" strategy provides a strong defense against Trojan
horses.  The second strategy takes a different approach that focuses
on individual application programs - particularly root-privileged
network servers.  Projects based on the second strategy enforce rules
that limit the resources available to application programs to the
absolute minimum set required for them to function properly.  Although
this "least privilege" strategy does not necessarily prevent the
spread of Trojan horses as described in section 3, it does severely
limit the ability of compromised network servers to do harm.  As
described in section 7, LOMAC's ordered-levels approach does not
perform well in this regard - a compromised level-1 network server is
free to corrupt other level-1 processes and files.  A protection
mechanism based on the least-privilege strategy would limit the harm
caused by compromised servers to a much smaller set of resources.

Both the ordered-level and least-privilege strategies provide some
useful integrity protection.  An optimal solution might use both
strategies simultaneously.  In fact, mechanisms based on Type
Enforcement (TE) model [BOE85] or its derivative Domain and Type
Enforcement (DTE) [BAD95] can enforce policies that make use of both
strategies.  However, doing so raises compatibility issues: In order
to implement an ordered-level scheme, the protection mechanism must
not allow privileged high-integrity processes to read low-integrity
files without demoting them, as LOMAC does.  However, TE does not
provide a mechanism for demoting processes on read operations.
Consequently, TE-based ordered-level policies are forced to prevent
privileged high-integrity processes from reading low-integrity files
at all.  As a result, the privileged high-integrity administrative
users on such systems must be blind to all low-integrity files, such as
low-integrity user directories, downloads, or email - an arrangement
that is very unusual from a traditional UNIX perspective.  Because of
this compatibility cost, all of the TE-based projects listed below
focus on providing protection according to the least-privilege
strategy, and do not provide examples of the ordered-level strategy,
even though their mechanisms may be capable of doing so.

A list of short project descriptions follows.  Each entry in the list
describes a project's theoretical capabilities without consideration
for the completeness and quality of the actual source code.  After the
list, there is a table which summarizes the comparisons between LOMAC
and these related projects.  I encourage readers to send me
corrections for any errors and omissions they find in this section.

  1.  FreeDTE

      FreeDTE is NAI Lab's implementation of DTE in the FreeBSD
      kernel, along with some supporting modified user-space
      applications.  FreeDTE has not, to date, been publicly released.

  2.  Generic Software Wrappers Toolkit
      ftp://ftp.tislabs.com/pub/wrappers

      NAI Labs' Generic Software Wrappers project has produced a
      toolkit for constructing abstract security enhancements called
      Wrappers, which are similar in purpose to SCC's Kernel
      Hypervisors, also listed here.  The toolkit provides a
      life-cycle abstraction for managing the relationships between
      Wrappers and processes, and a language for writing Wrappers with
      the potential for cross-platform portability.  The toolkit
      currently supports Linux, FreeBSD, Solaris, and (to some extent)
      Windows NT.  Like LOMAC, it uses an LKM to ensure compatibility.
      Unlike LOMAC, the toolkit is a general tool for constructing
      security enhancements, rather than an implementation of a
      particular MAC scheme.  I imagine that something like LOMAC
      could be implemented with Generic Software Wrappers.

  3.  Kernel Hypervisors
      http://www.securecomputing.com/khyper/index.html

      Secure Computing Corporation's Kernel Hypervisors are LKMs which
      "wrap" applications by replacing a subset of the kernel's system
      call interface with their own augmented interface.  The
      augmented interface may filter calls in order to perform access
      control, or may augment calls with new functionality, such as
      auditing.  Since it relies on LKMs, this project has a
      compatibility advantage similar to LOMAC's.  Furthermore, Kernel
      Hypervisors are a general tool that can be used to implement a
      wide variety of security-related functionality.  I imagine that
      Kernel Hypervisors could be used to implement something like
      LOMAC.  A Linux prototype is available.

  4.  Linux Intrusion Detection/Defense System (LIDS)
      http://www.lids.org

      LIDS is a kernel patch that provides some access control
      and intrusion detection functionality.

  5.  MAC
      http://users.ox.ac.uk/~mbeattie/linux

      MAC implements an integrity-oriented form of MAC in a kernel
      patch and a filesystem module.


  6.  Medusa DS9
      http://medusa.fornax.sk

      Medusa DS9 provides a mechanism for implementing general
      security functionality, including MAC.  It is implemented as a
      small Linux kernel patch that provides a service interface to a
      user-space security daemon.  This security daemon implements the
      majority of the desired security functionality, keeping these
      details out of the kernel.  Currently, a security daemon called
      "constable" has been implemented that acts as an authorization
      server.  I presume that it would be possible to implement a
      security daemon with functionality similar to LOMAC.

  7.  Pitbull LX
      http://www.argus-systems.com/products/white_paper/lx/

      Pitbull LX is an LKM that, like LOMAC, can be used to enhance
      the security of standard Linux kernels without modifying the
      kernel source.  Pitbull LX implements a form of TE similar to
      the one found in SubDomain (also listed here).  It uses PAM to
      avoid TE's usual requirement user-space application
      modification.

  7.  Rule Set Based Access Control (RSBAC) for Linux
      http://www.compuniverse.com/rsbac 

      Unlike LOMAC's focus on its single Low Water-Mark scheme, RSBAC
      is a Linux kernel patch that provides generalized support for
      many MAC policy models, where the decision-making functions for
      each model are implemented in a separate module.  Modules
      already exist for several models, including the Bell-La Padula
      (MULTICS) model and a Role Compatibility model similar to TE.

  8.  SAIC DTE
      http://research-cistw.saic.com/cace/dte.html

      SAIC is implementing DTE in Linux by modifying the kernel
      source.

  9.  Security-Enhanced Linux (selinux)
      http://www.nsa.gov/selinux

      The National Security Agency's Security-Enhanced Linux
      implements TE by modifying the kernel source, and the source of
      some supporting applications.

  10. SubDomain
      http://immunix.org

      SubDomain implements a form of MAC similar to DTE; its
      configuration retains the notion of domain, but does not make
      use of types.  SubDomain makes use of a small kernel patch to
      support its otherwise LKM-based implementation.  

  11. VXE
      http://www.intes.odessa.ua/vxe
      
      VXE enforces the principle of least privilege by confining
      processes (such as root-privileged network servers) to virtual
      environments in which only the minimum set of resources required
      for normal operation are available.  VXE virtual environments
      are implemented in LKMs and operate with the help of a Linux
      kernel patch.  Since these virtual environments may be tailored
      specifically to the resource needs of a particular application,
      VXE provides fine-grained support for restricting applications
      to least privilege.

  12. William & Mary DTE
      http://www.cs.wm.edu/~hallyn/dte/

      This is an implementation of DTE accomplished by modifying the
      kernel source from the college of William & Mary.


The following table compares the above projects and LOMAC according to
a list of functionality, protection, and compatibility criteria.  Each
project is rated against some or all of the criteria in a yes/no
fashion.  The criteria are as follows:

  focuses primarily on the least-privilege protection strategy:
      Projects whose examples or documentation emphasize
      least-privilege protection without ordered-level protection are
      marked "y" in this category, even if they are theoretically
      capable of enforcing policies based on both strategies.
      Projects which, like LOMAC, emphasize ordered-level protection
      are marked "n".  Projects which emphasize general support for
      multiple kinds of MAC are left blank.

  focuses primarily on the ordered-levels protection strategy:
      This is the ordered-levels equivalent of the previous criterion.

  requires no site-, application-, or user-specific policy configuration,
  requires no modified user-space applications, requires no kernel patch:
      These are compatibility criteria.  I have left some of these
      entries blank in cases where I was not certain of the proper
      value.

  provides general kernel extension support (not just MAC): This
      criteria marks projects whose main goal is general support for
      kernel extensions.  These projects are apt to have useful
      non-MAC-oriented functionality that is not discussed in this
      section.


focuses primarily on the least-privilege protection strategy --------------+
focuses primarily on the ordered-levels protection strategy -------------+ |
requires no site-, application-, or user-specific policy configuration + | |
requires no modified user-space applications ------------------------+ | | |
requires no kernel patch ------------------------------------------+ | | | |
provides general kernel extension support (not just MAC) --------+ | | | | |
                                                                 | | | | | |
                                                           LOMAC n y y y y n
                                                         FreeDTE n n n n n y
                                       Generic Software Wrappers y y y n   
                                              Kernel Hypervisors y y y n 
                                                            LIDS n n   n 
                                                      Pitbull LX n y y n n y
                                                             MAC n n n n y n
                                                      Medusa DS9 y n   n 
                                                           RSBAC n n   n 
                                                        SAIC DTE n n n n n y
                                         Security-Enhanced Linux n n n n n y
                                                       SubDomain n n y n n y
                                                             VXE n n   n n y
                                                William&Mary DTE n n   n n y

The table shows that LOMAC provides the most compatible solution of
the projects considered.  Pitbull LX is the most notable runner-up.
Although it avoids modifications of existing software, it requires
site-, user- and application-specific configuration.  It also
implements a form of TE, which would introduce further compatibility
issues if Pitbull LX were configured to enforce the kind of
ordered-level policy required to provide a comprehensive defense
against Trojan horses.  

Two of the generic kernel extension mechanisms, Generic Software
Wrappers and Kernel Hypervisors, also score well in terms of
compatibility.  It may be possible to implement LOMAC-like
functionality in either of these mechanisms.  However, generality may
come at the cost of performance.  For example, the minimum overhead
associated with the use of Generic Software Wrappers as measured by a
kernel-building performance benchmark is approximately seven times
greater than LOMAC's on a similar benchmark [FRA99].


[ References ]

[BAD95] L. Badger, et. al., "A Domain and Type Enforcement UNIX
        Prototype," Proceedings of the 5th USENIX UNIX Security
        Symposium, June, 1995.  Also USENIX Computing Systems, Vol. 9,
        No. 1, Winter 1996.
[BIB77] K. J. Biba, "Integrity Considerations for Secure Computer
        Systems," Electronic Systems Division, Hanscom Air Force Base,
        Bedford, MA, April 1977, pages 27-31.
[BOE85] W. E. Boebert and R. Y. Kain, "A Practical Alternative to
        Hierarchical Integrity Policies," Proceedings of the 8th
        National Computer Security Conference, 1985.  LWM and Trust:
        pages 19-20.  Assured Pipelines: pages 20-25.
[FRA99] Fraser, Badger, and Feldman, "Hardening COTS Software with
        Generic Software Wrappers," Proceedings of the 1999 IEEE
        Symposium on Security and Privacy, May, 1999.
[FRA00] T. Fraser "LOMAC: Low Water-Mark Integrity Protection for COTS
        Environments", Proceedings of the 2000 IEEE Symposium on
        Security and Privacy, 2000.
[SAL75] J. H. Saltzer and M. D. Schroeder, "The Protection of
        Information in Computer Systems," Proceedings of the IEEE
        Vol. 63(9), September 1975, pages 1278-1308.  Also summarized
        in Dorothy E. Denning, "Cryptography and Data Security,"
        Addison-Wesley, 1982, page 206.



   BSD is a trademark of the University of California, Berkeley,
   California.  FreeBSD is a Registered Trade Mark of FreeBSD,
   Inc. and Walnut Creek CDROM.  Pentium and Pentium II are Registered
   Trade Marks of the Intel Corporation.  Pitbull LX is a Registered
   Trade Mark of Argus Systems Group, Inc.  Red Hat is a Registered
   Trade Mark of Red Hat, Inc.  Solaris is a Registered Trade Mark of
   Sun Microsystems, Inc.  System V is a trademark of the American
   Telephone and Telegraph Company.  UNIX is a Registered Trade Mark
   of The Open Group.  Windows NT is a Registered Trade Mark of the
   Microsoft Corporation.
