Re: Re: Application Sandboxing, communication limiting, etc.

[Crispin Cowan <crispin () immunix com>]

Jared W. Robinson wrote:


This is exactly what Immunix SubDomain does: define the files and
network activities that each program may access. We use use regular
expressions to specify policy, so for instance, fingerd could be
permitted to read /home/*/.plan and not read anything else.
   


I'm glad to hear that SubDomain exists. Can you extend the idea for
individual Python/Perl scripts, or do you have to restrict all
Python/Perl scripts with one policy?

If you invoke the script via an execution path and the script starts 
with "#!/bin/perl" or something similar, then the profile is selected 
based on the path to the script. Only if you invoke the script from the 
command line in the form of "/usr/bin/perl /path/to/my/script" do you 
get a profile associated with the Perl interpreter.


Further, SubDomain provides a unique capability to confine web server 
scripts executed from Apache when interpreted via mod_perl and mod_php. 
The Immunix version of Apache includes a SubDomain hook that changes the 
protection domain before interpreting the script. So you don't have to 
give up security and run all your CGIs from a single protection domain 
just to get Apache module performance.



How does SubDomain compare to SELinux, systrace, etc? What are the
strengths and weaknesses of each?


SELinux:

   * SELinux is attribute based, while SubDomain is name-based
         o SELinux: you go tag all your files and processes with
           extended attributes. The extended attributes are then used
           to determine policy.
         o SubDomain writes policies as text lists of absolute path
           names that can be accessed, including regular expressions.
   * Non-existent files:
         o SELinux can create policies for non-existent files that will
           be created later, but only via existent directories and
           their children.
         o SubDomain can create policies for arbitrary non-existent
           files by just writing the path name of the anticipated file
           into the policy.
   * Mandatory vs. Semi-discretionary.
         o SELinux is truly mandatory: you have to apply SELinux policy
           to every file and process in your system.
         o SubDomain is semi-discretionary: you can apply SubDomain to
           only the processes you care about. SubDomain then
           automatically inherits policy to children of confined
           processes, and leaves the others alone. This is arguably
           less secure, but it is considerably more convenient. It is
           sufficiently secure if you consider your threat model (e.g.
           network attacks) and ensure that every process with an open
           network port is confined with SubDomain. Immunix notably
           comes with a utility to scan your machine for programs that
           have open network ports but do not have SubDomain profiles.
   * Complexity:
         o SELinux has about 60 modified system calls and 50 or so
           modified fileutils commands.
         o SubDomain has one system call and about a dozen profile
           development utilities. But because SubDomain does not depend
           on extended attributes, standard fileutils work normally.
   * Expressiveness:
         o Because SELinux is more complex, it can express policies
           that SubDomain is not so good at. In particular, because of
           its legacy in older timeshare systems, SELinux is better at
           managing controlled information sharing among users on a
           timeshare system, e.g. managing the accounting, engineering,
           and marketing departments on a shared computer.
         o SubDomain was designed in the late 1990s for network
           servers, and so is application-oriented rather than
           user-oriented. This gives SubDomain the ability to express
           other policies that SELinux cannot, such as the above cases
           about sub-process confinement (Apache mod_perl and mod_php
           scripts) and policies for files that do not yet exist.
           However, SubDomain can manage what users can do by giving
           them a special shell, e.g. /bin/restrictedshell is a hard
           link to /bin/bash, and create a profile for
           /bin/restrictedshell that describes what users who have a
           login shell of /bin/restrictedshell may do. We used this to
           good effect in the Defcon 2002 Capture-the-Flag game, where
           game rules effectively required you to allow attackers a
           root login shell. Other teams tried to kill attacking logins
           ASAP, while we just restricted them and watched them flail,
           taunting them by writing messages to their tty.

Systrace: Is much closer to SubDomain. Like SubDomain, Systrace attachs 
mediation to what a program can do. Systrace then lets you specify the 
parameters to the syscalls, giving you an indirect way to specify the 
files a program may access.


   * You can get the file access semantics of SubDomain with Systrace,
     but at the cost of more complex specification (you have to
     consistently specify the files that can accessed through open,
     creat, unlink, read, write, etc., while SubDomain just abstracts
     that to Read, Write, and Execute permissions (similar to UNIX RWX
     mode bits).
   * Systrace does not have the sub-process confinement (mod_perl and
     mod_php) capability.



Does any distribution besides Immunix use SubDomain?

No, Immunix is proprietary. We are a technology company; our goal is to 
license Immunix technologies (including SubDomain) to server appliance 
vendors to enable them to enhance their product security and reduce 
their cost of achieving security in their products.



What percentage of
applications have SubDomain policies written for them?

"Percent" is not a meaningful question. On one hand, Immunix ships with 
a SubDomain profile all of the applications that install by default with 
an open network port. On the other hand, a very small percentage of the 
6000 or so applications in Debian-unstable have SubDomain profiles. The 
important question for a given machine is "are all the threatened 
applications profiled?" and that answer varies with the configuration. 
As I said, Immunix comes with utilities to help assess that.



I imagine it's a
lot of work to write these policies.

IMHO, it is a lot easier to write SubDomain application policies than in 
any other access control system that I have seen. Your opinions may vary 
:) but that's why I provided the Mozilla profile, so people could check 
it out and see how easy or hard it is.


Crispin

--
Crispin Cowan, Ph.D.  http://immunix.com/~crispin/
CTO, Immunix          http://immunix.com
Immunix 7.3           http://www.immunix.com/shop/