Summary of paper "Operating System Enhancement to Prevent the Misuse
of System Calls" from 12/05


========================================================================
The authors start out by saying that the conventional techniques for
intrusion detection are reactive instead of proactive.  The reactive
techniques include

    1.  examination of logs files for anomolies
    2.  comparison of critical system files for changes

The authors propose the use of a reference monitor for system calls.
The idea is to detect and intercept illegal invocation of (so-called)
critical system calls; implement the changes at a level so that user
programs do not need to be changed; and make it effecient.

The reference monitor uses an access control database to aid in the
decision of whether to grant access to a system resource.  The generic
approach has the monitor mediate all accesses to system resources
and adds a constant cost. 

The novelty of the approach in this paper is that the monitor function
dumps out fairly quickly if it deems there is _no_possibility_ of
the call being used in an attack.  This is done by analyzing and
classifying system calls that can be used for a class of attacks
(that of overwriting buffers).



Remarks/Points/Issues
========================================================================

    1.  Information regarding files in the setuid-exec list have not
        only the filename stored, but the inode.  There are several
        instances where the inode may be changed (a backup or a
        patch, for instance).  Maintenance of the access control
        database would have to account for these possible changes.
        If this sort of incremental maintenance is not performed,
        it was pointed out that "Matt's root kit" could potentially
        be installed on a formerly "secure" inode.


    2.  Reference monitors are not a new concept ("old and slow").
        The novel thing presented in the paper is the classification
        of the syscalls in "threat levels".  A couple of issues with
        the classification:

          a.  Is the classification correct and complete?
          b.  The classification has to be done for every
              kernel/platfrom
  c.  The classification has to be reviewed/update at every
      patch (although it was mentioned that this could be
      the vendor's responsibility).

    3.  Performance meausures as presented were not very meaningful.
        Although the tests performed are fairly minimal, situations
        exist where critical machines may be using "critical" syscalls
        predominantly (a mail server will be using open/link/unlink
        predominantly; inetd calls fork/exec)


    4.  There are legitimate reasons to switch between two
        non-priveleged users (for example, from normal user to perhaps
        web account) which requires the use of su which would need
        access to the shadow file, which in turn reuires the root
        password in this scheme.

    5.  This method doesn't do anything for DOS attacks, and if the
        auditing log is kept in RAM, could lead to a DOS.