[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: chroot administration



On Wed, 14 Aug 2002 12:50, Sam Vilain wrote:
> > argh. its so cool that you essentially stole my summer research. :(.
> > Does this allow you to create any amount of chroot jails?  We are also
> > working on making "virtual IPs" that each jail would get.  We are also
> > working on being able to move the processes while running (w/ network
> > connections) from machine to machine w/o needing any state on initial
> > machine.
>
> You might want to investiage `security contexts', a new kernel feature
> that can be used for virtual IP roots as well as making processes in
> one context (even root) not able to see other contexts' processes.
> The userland utilities also offer a way to remove Linux's capabilities
> (eg, to disallow raw sockets or bypassing filesystem permissions).
>
> http://www.solucorp.qc.ca/miscprj/s_context.hc

Is someone going to package this for Debian?

There are some limitations with it.  The biggest limitation when compared to 
my SE Linux work is it's lack of flexibility.  I can setup a SE Linux chroot, 
then do a bind mount of /home/www, and grant read-only access to the files 
and directories of user_home_t and search access to directories of type 
user_home_dir_t.

In my default policy I have given the user who starts the chroot environment 
full access to files and directories in the chroot (of course if their UID!=0 
then they won't be able to do much).  Also in my policy I have two different 
security domains, one for all programs which has limited write access, and 
another for administration tools (such as dpkg/dselect) which can write all 
files and directories.  I could make an addition to this and have another 
file type which is append-only for the ordinary chroot domain and can only be 
read by the user who starts the chroot and the super domain.  This would 
greatly limit the ability of someone who breaks the security of a chroot 
environment.

The advantage of my work is that it's all in policy files that can easily be 
changed - you could even change the policy at run-time and grant different 
permissions to running processes!

The advantage of the "security contexts" system described on that web page is 
a comprehensive solution to the IP address issue (I've got a design but no 
working code so far).  I don't expect to ever get a solution that works as 
well as their solution unless/until new features are added to SE Linux.

-- 
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.



Reply to: