Secure Coding mailing list archives
Re: Re: Application Sandboxing, communication limiting, etc.
From: Crispin Cowan <crispin () immunix com>
Date: Tue, 16 Mar 2004 20:34:31 +0000
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/
Current thread:
- Re: Opinion re an interesting article on Linux security in Linux Journal, (continued)
- Re: Opinion re an interesting article on Linux security in Linux Journal ljknews (Mar 10)
- Re: Opinion re an interesting article on Linux security in Linux Journal der Mouse (Mar 10)
- Re: Opinion re an interesting article on Linux security in Linux Journal Bill Cheswick (Mar 10)
- Re: Application Sandboxing, communication limiting, etc. Jared W. Robinson (Mar 10)
- Re: Application Sandboxing, communication limiting, etc. ljknews (Mar 10)
- Re: Re: Application Sandboxing, communication limiting, etc. Jose Nazario (Mar 10)
- Re: Re: Application Sandboxing, communication limiting, etc. Crispin Cowan (Mar 13)
- Re: Re: Application Sandboxing, communication limiting, etc. Jared W. Robinson (Mar 16)
- Re: Application Sandboxing, communication limiting, etc. Jared W. Robinson (Mar 10)
- Re: Re: Application Sandboxing, communication limiting, etc. Crispin Cowan (Mar 14)
- Re: Re: Application Sandboxing, communication limiting, etc. Jared W. Robinson (Mar 16)
- Re: Re: Application Sandboxing, communication limiting, etc. Crispin Cowan (Mar 16)
- Re: Comparison of SubDomain, SELinux and systrace Jared W. Robinson (Mar 16)
- Re: Opinion re an interesting article on Linux security in Linux Journal ljknews (Mar 10)