Policy Generation Hueristics

Circa Feb 21, 2003

Heuristic Zero.  Minimal Program Launching.
Every program has to be launched.  There are a limited number of common ways to launch a program: as a user (with say user_t type), as a system admin (with sysadm_t type), from cron, or from init via an rc script, or from "other" programs/types.
To allow for tracking the launching (and killing) every program gets its own type, and at least one type transition statement that allows the program to be launched and run in its own security context, and assignments of contexts of program/executable and components.  When the program is launched, all  "deny" messages associated with the program's operation will now be recorded in terms the "seed" types, and these deny messages can be converted to "allow" statements and added to the program's policy file to generate a (very) simple policy that allows the program to be launched.

Heuristic One.  Type Transitions for Children.
Executables whose runtime type differ from their default type are candidates for domain transitions
    Not all programs require type transitions, depending upon the security model one is trying to implement and the policy "style".
A simple user utility such as ping might only require a single type transition from user_t to ping_t, and sufficient permissions for the ping program to access network resources, and send information back to the user's shell, and exit.
Servers, however, commonly require more involved type transitions.
    We note however that a common place to consider type transitions is when a given program has executed code outside of its own security context. Consider for example the case of an sshd server that is started from init and listens for connections, all in its own context (sshd_t).  A connection attempt to that server would typically involve spawning a child process, some authentication phase, and then if successful a login session.  Now if the child process and login session remain in the same context, then any resources that the user attempts to get would be denied.
    One can add access to those resources, which without a type transition would mean assigning more an more access to the sshd type.  The prefered practice though is to initiate a type transition, in this case to transition the sshd child session to the user type, after the authentication process is complete.  
    The question to address is: how might one identify the need for this sort of type transition?
    One answer is: look for cases where the initial type ( here sshd_t ) has launched a program/executable (such as /bin/bash) where the default file context of that executable is different from its run-time context (boy we need to restate this....).
    So here is a good place to do a simple test : does default file context = running file context?  If not, then that implies that this is a candidate for some form of transition.  What's nice about this is that one doesn't need an intimate understanding of the behavior of the program: just a simple comparison operation.


    Things to do here:
        1.  try a revamped policy of sshd using the new idea...
        2.  try making programs for other policies...
        3.  further inspection/ iteration
        4.  if happy, update spec for this heuristic.
        5.  Study of macros and their use (And abuse ?)
       
Other ideas for heuristics :

    Common logging practices

    Common techniques for accessing temp directories.

    Common IPC practices...

Along these lines: slowly growing the number of types (and components labeled with those types) is a good thing

Further IDEA (not necessarily a heuristic... but it just comes to mind):
Classify the various existing types into more abstract components (NETWORK, SHELL, WINDOW, DEVICE, LOG, ADMINFILES, USERFILES, COMMONFILES, SYSTEMEXECS, USEREXECS, USERLIBRARIES, SYSTEMLIBRARIES)