/*************************************************************************
 *
 * This file lists known LOMAC bugs, deficiencies, and correct behaviors
 * deemed sufficiently surprising to require explanation.
 *
 *************************************************************************/

o XDM (logging in via X) - doesn't yet work with LOMAC's default policy

  From the LOMAC v0.3pre6 announcement on the lomac-users mailing list:

  The PLM is the "Path-Level Map" - the data structure that maps
  levels to files in the filesystem namespace.  Its default
  configuration presently has a problem concerning /var/log/lastlog.
  /sbin/init reads from this file.  This fact compels us to set
  /var/log/lastlog at the high level, since if /sbin/init ever reads a
  low file, it will be demoted, and will subsequently have
  insufficient privilege to shut down the machine.
  
  However, sessreg - part of the XDM suite of programs for managing X
  logins - needs /var/log/lastlog to be low so it can write to it at
  the start of each user session.  It seems (after a few minimal
  tests) that sessreg won't start a session unless it can write to
  /var/log/lastlog.  The present PLM configuration sets
  /var/log/lastlog high, so if you boot your machine into runlevel 5
  (X) and use an XDM configuration that uses sessreg, you will not be
  able to log in via X.  You can rescue yourself by hitting
  CTRL-ALT-F1 and logging in at a virtual console.
  
  If you boot your machine into runlevel 3 (multiuser) and start X
  manually via "xinit" or "startx", you will not experience this
  problem.  I hope to fix this sessreg problem, soon.

o Hardlinks - can confuse LOMAC

  LOMAC determines the proper level for a file based on its filename.
  If a file has two names (via hardlinks), where one name indicated
  level-1 and the other level-2, LOMAC will pick one level or the
  other depending on the name used to open the file.  Symbolic links
  do not confuse LOMAC.

o NFSD - mediation

  No mediation is done on the kernel nfsd.

o cp - surprising behavior

  There is a surprising (although correct) behavior when running cp at
  level 2, trying to copy a level-1 file over an existing level-2
  file:

  1.  cp asks, "overwrite?"  you answer yes.
  2.  cp (still at level 2) truncates existing level-2 file.
  3.  cp reads level-1 file and gets demoted.
  4.  cp, now at level 1, can't write new level-2 file.
  5.  you wind up with a 0-length level-2 file.  (ouch!)

o UNIX domain sockets - grandfathering 

  The UNIX domain socket grandfathering code for non-bound sockets
  needs to be improved.  (Grandfathering refers to assigning levels to
  pre-existing objects at LOMAC load time).  The current code is
  security-safe, but is overly pessimistic - some sockets get level 1
  when they could safely be given level 2.

o Bad copyin discipline

  The current kernel_wrappers.c implementation is full of
  time-of-check - time-of-use errors on syscall parameters.  This is a
  security-relevant bug.  These bugs allow a malicious multithreaded
  level-1 program to attempt to bypass LOMAC's controls using the
  following algorithm:

  THREAD 1:                                 THREAD 2:
    DO                                        DO
      char *filename = "level1file"             filename = "level2file"
      unlink( filename )                      MANY TIMES
    MANY TIMES 

  The unlink will probably harmlessly unlink "level1file" for many
  iterations until the timing happens to work out as follows:
  
  THREAD1 filename = "level1file"
  THREAD1 make unlink( filename ) syscall
    LOMAC   copyin path "level1file"
    LOMAC   decide that unlink is permissible (this operation can block)
    THREAD2 filename = "level2file"
    KERNEL  copyin path "level2file" 
    KERNEL  unlink "level2file"   /* oops! */
  THREAD1 return from unlink syscall

  This problem can be fixed by eliminating the multiple copyins of the
  same parameter.

o Directories - no modification mediation

  LOMAC does not presently control directory modifications.  For
  example, a level-1 process can create the level-1 file /tmp/foo,
  even though this means modifying the contents of the level-2
  directory /tmp.  This causes problems with /dev/log and
  /dev/printer.  These level-1 files are deletable by level-1
  processes, even though they are in a level-2 directory.  It would be
  better if they were not deletable, because both level-1 and level-2
  processes use them.

o Audit - just about everything's an open/creat

  The open/creat mediation routines get used to mediate many kinds of
  operations other than opens and creates.  For example, these
  routines mediate binds and unlinks.  Unfortunately, the log messages
  these routines produce is hard-coded to say "open/creat", so you'll
  see binds and unlinks identified as open/creats in
  /var/log/messages.  This is confusing, and will have to be fixed by
  parameterizing this log message functionality.

o SYS_SEND - insufficient mediation

  LOMAC does not control SYS_SEND, SYS_SENDTO, and SYS_SENDMSG calls
  used on UNIX-domain datagram sockets.

o System V IPC - no mediation or monitoring

  LOMAC does not control the use of System V IPC.

o Mediation - not all operations have sufficient controls.

  LOMAC presently controls (at least partially) these system calls:

    creat, ftruncate, kill, link, mkdir, mknod, mount, open, pipe,
    read, readv, reboot, rename, rmdir, setpgid, socketcall, truncate,
    umount, unlink, write, writev.

  A list of Linux system calls can be found in 

    /usr/src/linux/arch/<your arch>/kernel/entry.S

  Search for ENTRY(sys_call_table).  It shows many system calls that
  are not yet controlled by LOMAC.




