Jail: Problems? Proper Usage? Status? Practicality?

ver: FreeBSD 4.0-STABLE #0: Sun May 14 11:06:58 EDT 2000

I'm planning to use jail in the near future to do two things. First is to
generally increase the security of a system by putting services like http,
smtp, ftp, etc. into separate jails to decrease the potential harm of a
security hole. This system will only allow shell accesses to trusted
individuals. The second plan is to create multiple, virtual servers on
another host system. These virtual servers will allow shell access to
semi-trusted individuals, including the jail root user. Also the jail
administrator could potentially run unsecure services. This second plan is
tentative depending on the reliability of jail.

I have setup a test jail on my workstation with good results. The first
problem I have found is that I can't access the jailed IP at all from the
host system, nor the host system from the jailed one. However both host
and jailed IPs are accessible to other machines on the network. Is this
intentional? The jailed system can access the Internet fine through my natd 
setup on the host system (which actually surprised me). I'm aware that
raw sockets are not allowed to jailed processes but is there a workaround
for ping and traceroute?

Finally how secure is jail really? I'm aware of a trivial chroot breakout
technique. Does that hole still exist? Are there any other known holes? Is
jail still under active development? Is it worth the trouble to do any of
this?

Thanks.

------------------------------------------------------------------------------
|            Geoffrey Robinson           -          [e-mail]         |
------------------------------------------------------------------------------
                           Random Fortune Quote
When you're not looking at it, this fortune is written in FORTRAN.





To Unsubscribe: send mail to [e-mail]
with "unsubscribe freebsd-security" in the body of the message

> -------------------------------------------------------------------------- <

發信人: [e-mail] (Poul-Henning Kamp), 看板: FB_security
標  題: Re: Jail: Problems? Proper Usage? Status? Practicality?
發信站: NCTU CSIE FreeBSD Server (Tue May 16 17:04:43 2000)
轉信站: Ptt!FreeBSD.csie.NCTU!not-for-mail


>I have setup a test jail on my workstation with good results. The first
>problem I have found is that I can't access the jailed IP at all from the
>host system, nor the host system from the jailed one. However both host
>and jailed IPs are accessible to other machines on the network. Is this
>intentional?

Sounds like some kind of configuration error in your end.  It works fine
for me.  In general it is best to add the IP aliases to the lo0 interface.

>Finally how secure is jail really? 

I don't know of any way to escape.  There are a few known things where
someone in a jail can make a nuisance of themselves, but not a way for
them to break out.

>Is jail still under active development?

I would call it "under normal maintenance", there are no planned new
features on the way.

>Is it worth the trouble to do any of this?

Now how would *I* know ?  :-)

--
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[e-mail]         | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to [e-mail]
with "unsubscribe freebsd-security" in the body of the message

> -------------------------------------------------------------------------- <

發信人: [e-mail] (Robert Watson), 看板: FB_security
標  題: Re: Jail: Problems? Proper Usage? Status? Practicality?
發信站: NCTU CSIE FreeBSD Server (Wed May 17 09:05:43 2000)
轉信站: Ptt!FreeBSD.csie.NCTU!not-for-mail

On Mon, 15 May 2000, Geoffrey Robinson wrote:

> 
> ver: FreeBSD 4.0-STABLE #0: Sun May 14 11:06:58 EDT 2000
> 
> I'm planning to use jail in the near future to do two things. First is
> to generally increase the security of a system by putting services like
> http, smtp, ftp, etc. into separate jails to decrease the potential harm
> of a security hole. This system will only allow shell accesses to
> trusted individuals. The second plan is to create multiple, virtual
> servers on another host system. These virtual servers will allow shell
> access to semi-trusted individuals, including the jail root user. Also
> the jail administrator could potentially run unsecure services. This
> second plan is tentative depending on the reliability of jail. 
> 
> I have setup a test jail on my workstation with good results. The first
> problem I have found is that I can't access the jailed IP at all from
> the host system, nor the host system from the jailed one. However both
> host and jailed IPs are accessible to other machines on the network. Is
> this intentional? The jailed system can access the Internet fine through
> my natd setup on the host system (which actually surprised me). I'm

It sounds like a configuration error.  Jail merely limits the scope of
bindable addresses; it shouldn't limit connectivity between them unless
that limit existed without the jail present.  Check that you're aliasing
the IPs properly -- specifically, that you're adding IP aliases with a
netmask of 255.255.255.255.

> aware that raw sockets are not allowed to jailed processes but is there
> a workaround for ping and traceroute? 

Currently, no.  Due to the way raw sockets work (allowing listening for
all non-handled IP messages, and allowing direct writing of IP packets),
it would take a bit of work to get this up and running, although it would
be feasible.  A more promising long-term goal might be to better
virtualize network services, creating virtual interfaces and binding real
network resources to virtual interfaces.  However, that would be far more
work. :-)

> Finally how secure is jail really? I'm aware of a trivial chroot breakout
> technique. Does that hole still exist? Are there any other known holes? Is
> jail still under active development? Is it worth the trouble to do any of
> this?

As far as I know, none of the chroot() breakout mechanisms will work from
jail(), as long as the jail() file system is constructed and maintained in
a safe manner.  For example, jail() prevents new device nodes from being
introduced with mknod().  However, this assumes that (a) no improper
device nodes existed in the accessible file space in the first place, and
(b) root outside of jail() won't create them in the file space.

Jail is being actively maintained; I have some ideas for it in the long
term, but probably won't get to carrying them to fruition for a few
months.  This includes improved management capability (unique jailids,
ability to deliver a signal to an entire jail from outside the jail, as
well as special purpose binaries such as a jailinit to manage setup and
shutdown of jails in an orderly manner.  If you are interested in working
on such features, I'd be glad to share design thoughts with you, as it
will take me a while to get to this stuff.

Right now my efforts are primarily aimed at improving the security
abstractions within the kernel relating to the TrustedBSD project--this
should have a side benefit of improving the relationship between jail()
and the base OS, making Jail easier to maintain and modify.

  Robert N M Watson 

[e-mail]              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services



To Unsubscribe: send mail to [e-mail]
with "unsubscribe freebsd-security" in the body of the message

> -------------------------------------------------------------------------- <

發信人: [e-mail] (Geoffrey Robinson), 看板: FB_security
標  題: Re: Jail: Problems? Proper Usage? Status? Practicality?
發信站: NCTU CSIE FreeBSD Server (Wed May 17 13:01:19 2000)
轉信站: Ptt!FreeBSD.csie.NCTU!not-for-mail

On Tue, 16 May 2000, Robert Watson wrote:

> On Mon, 15 May 2000, Geoffrey Robinson wrote:
> 
> > 
> > ver: FreeBSD 4.0-STABLE #0: Sun May 14 11:06:58 EDT 2000
<snip>
> > aware that raw sockets are not allowed to jailed processes but is there
> > a workaround for ping and traceroute? 
> 
> Currently, no.  Due to the way raw sockets work (allowing listening for
> all non-handled IP messages, and allowing direct writing of IP packets),
> it would take a bit of work to get this up and running, although it would
> be feasible.  A more promising long-term goal might be to better
> virtualize network services, creating virtual interfaces and binding real
> network resources to virtual interfaces.  However, that would be far more
> work. :-)

If a process running in the host system created a UNIX domain socket or
named pipe within the jail directory tree. Would a process running in the
jail be able to connect to and communicate with the host process through
this socket or pipe? If so I guess you could create work around for just
about anything by running it on the host system. Would this create a
potential way of defeating the jail?

> As far as I know, none of the chroot() breakout mechanisms will work from
> jail(), as long as the jail() file system is constructed and maintained in
> a safe manner.  For example, jail() prevents new device nodes from being
> introduced with mknod().  However, this assumes that (a) no improper
> device nodes existed in the accessible file space in the first place, and
> (b) root outside of jail() won't create them in the file space.

What about upgrading procedures? After my last cvsup and make world 
on the host system the jail could be started but could not access the
network. I had to build a new jail from scratch to get it working properly. 

> Jail is being actively maintained; I have some ideas for it in the long
> term, but probably won't get to carrying them to fruition for a few
> months.  This includes improved management capability (unique jailids,
> ability to deliver a signal to an entire jail from outside the jail, as
> well as special purpose binaries such as a jailinit to manage setup and
> shutdown of jails in an orderly manner.  If you are interested in working
> on such features, I'd be glad to share design thoughts with you, as it
> will take me a while to get to this stuff.

I would like to try. I don't know how much help I could be. Please, let me
know what I can do. I'll do what I can.


------------------------------------------------------------------------------
|            Geoffrey Robinson           -          [e-mail]         |
------------------------------------------------------------------------------
                           Random Fortune Quote
"MacDonald has the gift on compressing the largest amount of words into
the smallest amount of thoughts."
		-- Winston Churchill




To Unsubscribe: send mail to [e-mail]
with "unsubscribe freebsd-security" in the body of the message

> -------------------------------------------------------------------------- <

發信人: [e-mail] (Chris Williams), 看板: FB_security
標  題: Re: Jail: Problems? Proper Usage? Status? Practicality?
發信站: NCTU CSIE FreeBSD Server (Thu May 18 05:49:50 2000)
轉信站: Ptt!FreeBSD.csie.NCTU!not-for-mail

> If a process running in the host system created a UNIX domain socket or
> named pipe within the jail directory tree. Would a process running in the
> jail be able to connect to and communicate with the host process through
> this socket or pipe? If so I guess you could create work around for just
> about anything by running it on the host system. Would this create a
> potential way of defeating the jail?

It does bring up the issue of buffer overflows and soforth in the
process on the unjailed end of the pipe.


To Unsubscribe: send mail to [e-mail]
with "unsubscribe freebsd-security" in the body of the message

> -------------------------------------------------------------------------- <

發信人: [e-mail] (Robert Watson), 看板: FB_security
標  題: Re: Jail: Problems? Proper Usage? Status? Practicality?
發信站: NCTU CSIE FreeBSD Server (Thu May 18 07:06:38 2000)
轉信站: Ptt!FreeBSD.csie.NCTU!not-for-mail

On Tue, 16 May 2000, Geoffrey Robinson wrote:

> On Tue, 16 May 2000, Robert Watson wrote:
> 
> > On Mon, 15 May 2000, Geoffrey Robinson wrote:
> > 
> > > ver: FreeBSD 4.0-STABLE #0: Sun May 14 11:06:58 EDT 2000
> <snip>
> > > aware that raw sockets are not allowed to jailed processes but is there
> > > a workaround for ping and traceroute? 
> > 
> > Currently, no.  Due to the way raw sockets work (allowing listening for
> > all non-handled IP messages, and allowing direct writing of IP packets),
> > it would take a bit of work to get this up and running, although it would
> > be feasible.  A more promising long-term goal might be to better
> > virtualize network services, creating virtual interfaces and binding real
> > network resources to virtual interfaces.  However, that would be far more
> > work. :-)
> 
> If a process running in the host system created a UNIX domain socket or
> named pipe within the jail directory tree. Would a process running in the
> jail be able to connect to and communicate with the host process through
> this socket or pipe? If so I guess you could create work around for just
> about anything by running it on the host system. Would this create a
> potential way of defeating the jail?

Jail works by:

1) Chrooting the child process
2) Limiting the scope of superuser privileges accessible by uid0 processes
   in the jail

It does not attempt to prevent processes outside the jail from
communicating with processes within the jail.  As such, having a process
do so wouldn't defeat the jail per se, but would defeat the purpose of the
jail :-).

> 
> > As far as I know, none of the chroot() breakout mechanisms will work from
> > jail(), as long as the jail() file system is constructed and maintained in
> > a safe manner.  For example, jail() prevents new device nodes from being
> > introduced with mknod().  However, this assumes that (a) no improper
> > device nodes existed in the accessible file space in the first place, and
> > (b) root outside of jail() won't create them in the file space.
> 
> What about upgrading procedures? After my last cvsup and make world 
> on the host system the jail could be started but could not access the
> network. I had to build a new jail from scratch to get it working properly. 

I'm not clear on why that would happen -- the libc (etc, etc) in each jail
should be kept in synch with the kernel, however, and that could be source
of your problems.  I.e., if you upgrade the kernel, it exports the same
syscall interface to all processes, regardless of jails, so all jails
making use of syscalls that have changed need to be upgraded in synch. 

This is the same as upgrading the kernel without upgrading your normal
world.

One way to substantially improve jail scalability would be to allow the
same (read-only) file system to be present in all jails as the root, with
only jail-local data being modified.  You can imagine gratuitously using
nullfs (if it worked) to do this, and mount per-jail writable fs's for
appropriatel subdirectories (/etc, /usr/local, /home) with appropriate
symlinks within the jail.  Right now, each jail costs you the size of
world, and is hard to upgrade if you have any decent number of jails.
Storing all that stuff in a single tree mapped read-only into jails would
solve that (you'd probably want two so you could upgrade one, test it, and
then swap to that for all jails so as to minimize downtime).

> > Jail is being actively maintained; I have some ideas for it in the long
> > term, but probably won't get to carrying them to fruition for a few
> > months.  This includes improved management capability (unique jailids,
> > ability to deliver a signal to an entire jail from outside the jail, as
> > well as special purpose binaries such as a jailinit to manage setup and
> > shutdown of jails in an orderly manner.  If you are interested in working
> > on such features, I'd be glad to share design thoughts with you, as it
> > will take me a while to get to this stuff.
> 
> I would like to try. I don't know how much help I could be. Please, let me
> know what I can do. I'll do what I can.

I'll gather up my notes on possible improvements and post them to
-security sometime in the next week or two.  Thanks!

  Robert N M Watson 

[e-mail]              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services




To Unsubscribe: send mail to [e-mail]
with "unsubscribe freebsd-security" in the body of the message

> -------------------------------------------------------------------------- <

發信人: [e-mail] ("Jacques A . Vidrine"), 看板: FB_security
標  題: Re: Jail: Problems? Proper Usage? Status? Practicality?
發信站: NCTU CSIE FreeBSD Server (Thu May 18 08:09:37 2000)
轉信站: Ptt!FreeBSD.csie.NCTU!not-for-mail

On Wed, May 17, 2000 at 11:05:07AM -0400, Robert Watson wrote:
> Jail works by:
> 
> 1) Chrooting the child process
> 2) Limiting the scope of superuser privileges accessible by uid0 processes
>    in the jail
  3) Limiting network access to a single IP address

[snip]
> Right now, each jail costs you the size of
> world, and is hard to upgrade if you have any decent number of jails.

You don't need the whole world depending on what you are doing.  If a
jail is setup for the purposes of a single application (which I expect
is the most common scenario), you only need the files that support it.

Upgrading the jail is simple if you created a script to create the jail
in the first place -- you re-run the script after upgrading the base
system.  

For me the real problem with this scheme is producing the script for
building a jail in the first place.  I do it by hand.  One of these days
I'd like to try writing an application that can generate a first-draft
script for building a jail, given a list of applications that need to
run in the jail.  I think it might be nifty to do this based on the
output of a ktrace on the target applications during a test run.

> Storing all that stuff in a single tree mapped read-only into jails would
> solve that (you'd probably want two so you could upgrade one, test it, and
> then swap to that for all jails so as to minimize downtime).

I don't think you want this unless the purpose of your jail is to
provide a `complete virtual server' for shell access et. al.  I don't
want e.g. `cc' or `sync' or most of the things in `/dev' to be available
to a jailed process.  

> I'll gather up my notes on possible improvements and post them to
> -security sometime in the next week or two.  Thanks!

Yay, thanks Robert!
-- 
Jacques Vidrine / [e-mail] / [e-mail]


To Unsubscribe: send mail to [e-mail]
with "unsubscribe freebsd-security" in the body of the message

> -------------------------------------------------------------------------- <

發信人: [e-mail] (Robert Watson), 看板: FB_security
標  題: Re: Jail: Problems? Proper Usage? Status? Practicality?
發信站: NCTU CSIE FreeBSD Server (Thu May 18 08:45:21 2000)
轉信站: Ptt!FreeBSD.csie.NCTU!not-for-mail

On Wed, 17 May 2000, Jacques A . Vidrine wrote:

> On Wed, May 17, 2000 at 11:05:07AM -0400, Robert Watson wrote:
> > Jail works by:
> > 
> > 1) Chrooting the child process
> > 2) Limiting the scope of superuser privileges accessible by uid0 processes
> >    in the jail
>   3) Limiting network access to a single IP address
> 
> [snip]
> > Right now, each jail costs you the size of
> > world, and is hard to upgrade if you have any decent number of jails.
> 
> You don't need the whole world depending on what you are doing.  If a
> jail is setup for the purposes of a single application (which I expect
> is the most common scenario), you only need the files that support it.

I had a script that built a much-reduced world necessary for a simple
virtual server environment.  As you suggest, it's possible to throw out
almost all of /sbin, substantial parts of {/bin,/usr/bin,/usr/sbin}, all
of /boot, /kernel, and so on.  Many of these utilities are used for
managing hardware, the boot process, etc, and are not relevant in a
restricted jail environment.  Sadly, my concise list of files got toasted
with a lost notebook hard disk, and I haven't had a chance to reproduce it
yet.  I probably will at some point.  Even so, by the time you've thrown
in a substantial /usr/lib and so on, you still have a decent sized chunk
that is identical across all jails.  A working read-only nullfs would
substantially improve this problem.

It also improves the backup situation: I can require (and enforce) that
all jail-specific data be stored in {/etc,/local/,var} off of the jail
root, and not worry that by upgrading /usr I'm going to wipe out local
files, and know that my backups catch everything.

> Upgrading the jail is simple if you created a script to create the jail
> in the first place -- you re-run the script after upgrading the base
> system.

Simple, but costly.  Imagine for a moment that you have 700 jails on a
single machine, and you'd like to be able to consistently announce to all
admins of all jails that a version upgrade is taking place on 5/16/2000,
and the downtime is one hour :-).  I'd rather have a single file system
exported to all jails, saving space and time.

> For me the real problem with this scheme is producing the script for
> building a jail in the first place.  I do it by hand.  One of these days
> I'd like to try writing an application that can generate a first-draft
> script for building a jail, given a list of applications that need to
> run in the jail.  I think it might be nifty to do this based on the
> output of a ktrace on the target applications during a test run.

I didn't have mine tuned quite that much, I just eliminated clearly
unnecessary things (dmesg, ipfw, ifconfig, ...).  Clearly what you
eliminate depends a lot on what you want to do with the jail.  You might
consider using some combination of nm and strings to pull out
dependencies, also.  I had a tool at one point that caught all read and
write references to files during the boot process, which I was using to
determine appropriate file settings for securelevel.  A similar idea for
jails would be a possibility, although that only catches the files that
were used, not the files that might be used :-).

> > Storing all that stuff in a single tree mapped read-only into jails would
> > solve that (you'd probably want two so you could upgrade one, test it, and
> > then swap to that for all jails so as to minimize downtime).
> 
> I don't think you want this unless the purpose of your jail is to
> provide a `complete virtual server' for shell access et. al.  I don't
> want e.g. `cc' or `sync' or most of the things in `/dev' to be available
> to a jailed process.  

The majority of /dev is already not available, or there would be security
problems. :-)

Again, I agree -- it's possible to substantially trim.  However, in the
environment I'm looking at, 30mb per-jail wasted is a lot of waste.  With
700 jails, that's 2.1gb of wasted space (which needs to be RAID for the
jails to be reliable), and also 2.1gb of copied files for each upgrade,
opening a substantial time window for problems to occur.  I'd like to be
able to (effectively) atomically upgrade a jail by shutting down the jail,
umounting its /usr reference, mounting the new /usr reference, and
restarting the jail. 

Needless to say, this would require two jail /usr partitions, one that was
to be moved in, one that would contain the old one while the move was in
progress.

> > I'll gather up my notes on possible improvements and post them to
> > -security sometime in the next week or two.  Thanks!
> 
> Yay, thanks Robert!

  Robert N M Watson 

[e-mail]              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services



To Unsubscribe: send mail to [e-mail]
with "unsubscribe freebsd-security" in the body of the message

> -------------------------------------------------------------------------- <

發信人: [e-mail] ("Morten Seeberg"), 看板: FB_security
標  題: Re: Jail: Problems? Proper Usage? Status? Practicality?
發信站: NCTU CSIE FreeBSD Server (Thu May 18 09:07:23 2000)
轉信站: Ptt!FreeBSD.csie.NCTU!not-for-mail

> One way to substantially improve jail scalability would be to allow the
> same (read-only) file system to be present in all jails as the root, with
> only jail-local data being modified.  You can imagine gratuitously using

I haven愒 had time to play with jail, but according to what PHK said at a
seminar
where he explained the jail functionality, he said that you could have just
1
filesystem, and mount it via NFS.



To Unsubscribe: send mail to [e-mail]
with "unsubscribe freebsd-security" in the body of the message

> -------------------------------------------------------------------------- <

發信人: [e-mail] ("Jacques A . Vidrine"), 看板: FB_security
標  題: Re: Jail: Problems? Proper Usage? Status? Practicality?
發信站: NCTU CSIE FreeBSD Server (Thu May 18 12:48:16 2000)
轉信站: Ptt!FreeBSD.csie.NCTU!not-for-mail

On Wed, May 17, 2000 at 12:41:49PM -0400, Robert Watson wrote:
> Simple, but costly.  Imagine for a moment that you have 700 jails on a
> single machine, and you'd like to be able to consistently announce to all
> admins of all jails that a version upgrade is taking place on 5/16/2000,
> and the downtime is one hour :-).  I'd rather have a single file system
> exported to all jails, saving space and time.

For a jail running apache+php+ssl (a fairly complex application), I
have ~3.4 MB of files from the base system (35 files).  This isn't
very large.  One need only store the file once per filesystem (hard
links).
 
> I didn't have mine tuned quite that much, I just eliminated clearly
> unnecessary things (dmesg, ipfw, ifconfig, ...).  Clearly what you
> eliminate depends a lot on what you want to do with the jail.  

I think this is backwards ... one should include in the jail only what
is needed, rather than eliminate things that are apparently unneeded.

> A similar idea for jails would be a possibility, although that only
> catches the files that were used, not the files that might be used
> :-).

Yep, determining all the paths that an arbitrary application might
access is NP-complete :-) But I think an excellent start could be
generated by looking at what namei translations are done on behalf of
a given process.

> I'd like to be
> able to (effectively) atomically upgrade a jail by shutting down the jail,
> umounting its /usr reference, mounting the new /usr reference, and
> restarting the jail. 

Yes, I think this is the best solution if (a) one has dozens of
jails, (b) the requirements of all of them are identical, and (c) the
number of files that are to be `shared' among the jails is large.
e.g. a public access unix system for web hosting or other.

I guess in the latter case, one has to be happy with local NFS mounts
at the moment, since VFS layering is, I believe, still buggy.
-- 
Jacques Vidrine / [e-mail] / [e-mail]


To Unsubscribe: send mail to [e-mail]
with "unsubscribe freebsd-security" in the body of the message

> -------------------------------------------------------------------------- <

發信人: [e-mail] (Dan Harnett), 看板: FB_security
標  題: Re: Jail: Problems? Proper Usage? Status? Practicality?
發信站: NCTU CSIE FreeBSD Server (Thu May 18 12:56:02 2000)
轉信站: Ptt!FreeBSD.csie.NCTU!not-for-mail

Hello, 

On Wed, May 17, 2000 at 03:26:21PM -0500, Jacques A . Vidrine wrote:
> On Wed, May 17, 2000 at 12:41:49PM -0400, Robert Watson wrote:
> > Simple, but costly.  Imagine for a moment that you have 700 jails on a
> > single machine, and you'd like to be able to consistently announce to all
> > admins of all jails that a version upgrade is taking place on 5/16/2000,
> > and the downtime is one hour :-).  I'd rather have a single file system
> > exported to all jails, saving space and time.
> 
> For a jail running apache+php+ssl (a fairly complex application), I
> have ~3.4 MB of files from the base system (35 files).  This isn't
> very large.  One need only store the file once per filesystem (hard
> links).

Isn't there a downside to that as well?  Unless the files are read-only, if 
one jail should get compromised any common shared files could actually lead to
holes in the remaining jails.  An example being a modified sshd or telnetd.

-- 
 Dan Harnett                                Wizard Communication Systems, Inc.
 Email: [e-mail]                       2 Main Street
 Phone: [phone]                      Tonawanda, NY  14150


To Unsubscribe: send mail to [e-mail]
with "unsubscribe freebsd-security" in the body of the message

> -------------------------------------------------------------------------- <

發信人: [e-mail] ("Jacques A . Vidrine"), 看板: FB_security
標  題: Re: Jail: Problems? Proper Usage? Status? Practicality?
發信站: NCTU CSIE FreeBSD Server (Thu May 18 12:56:10 2000)
轉信站: Ptt!FreeBSD.csie.NCTU!not-for-mail

On Wed, May 17, 2000 at 04:45:19PM -0400, Dan Harnett wrote:
> Isn't there a downside to that as well?  Unless the files are read-only, if 
> one jail should get compromised any common shared files could actually lead to
> holes in the remaining jails.  An example being a modified sshd or telnetd.

The assumption is that the files _are_ read-only, or even better, schg.
-- 
Jacques Vidrine / [e-mail] / [e-mail]


To Unsubscribe: send mail to [e-mail]
with "unsubscribe freebsd-security" in the body of the message

> -------------------------------------------------------------------------- <

發信人: [e-mail] (Don Lewis), 看板: FB_security
標  題: Re: Jail: Problems? Proper Usage? Status? Practicality?
發信站: NCTU CSIE FreeBSD Server (Thu May 18 14:33:26 2000)
轉信站: Ptt!FreeBSD.csie.NCTU!not-for-mail

On May 16,  1:05pm, Robert Watson wrote:
} Subject: Re: Jail: Problems? Proper Usage? Status? Practicality?
} On Mon, 15 May 2000, Geoffrey Robinson wrote:

} > aware that raw sockets are not allowed to jailed processes but is there
} > a workaround for ping and traceroute? 
} 
} Currently, no.  Due to the way raw sockets work (allowing listening for
} all non-handled IP messages, and allowing direct writing of IP packets),
} it would take a bit of work to get this up and running, although it would
} be feasible.  A more promising long-term goal might be to better
} virtualize network services, creating virtual interfaces and binding real
} network resources to virtual interfaces.

I think this is the right way to go.  The current jail implementation
is not compatible with IPv6, and there is no way to confine a dual homed
proxy server to a jail, since the jail is only allowed one IP address.
If the jail used virtual network interfaces, then it would be possible
to add packet filter rules to these network interfaces.  This would
be much more flexible than the current implementation, since it would
then be possible to have fine grained control over the network
connections allowed into and out of the jail.  It would also be possible
for multiple jails to share the same IP address but be restricted to
disjoint port ranges.

} > Finally how secure is jail really? I'm aware of a trivial chroot breakout
} > technique. Does that hole still exist? Are there any other known holes? Is
} > jail still under active development? Is it worth the trouble to do any of
} > this?

} Right now my efforts are primarily aimed at improving the security
} abstractions within the kernel relating to the TrustedBSD project--this
} should have a side benefit of improving the relationship between jail()
} and the base OS, making Jail easier to maintain and modify.

I think this is also the right thing to do.  I would go so far as to
deprecate the jail(2) syscall, and implement jail(8) in terms of
the syscalls to set up the virtual network interfaces, the syscalls
to set the process capabilities, and chroot().


To Unsubscribe: send mail to [e-mail]
with "unsubscribe freebsd-security" in the body of the message

> -------------------------------------------------------------------------- <

發信人: [e-mail] (Don Lewis), 看板: FB_security
標  題: Re: Jail: Problems? Proper Usage? Status? Practicality?
發信站: NCTU CSIE FreeBSD Server (Thu May 18 14:37:36 2000)
轉信站: Ptt!FreeBSD.csie.NCTU!not-for-mail

On May 17, 11:05am, Robert Watson wrote:
} Subject: Re: Jail: Problems? Proper Usage? Status? Practicality?

} One way to substantially improve jail scalability would be to allow the
} same (read-only) file system to be present in all jails as the root, with
} only jail-local data being modified.  You can imagine gratuitously using
} nullfs (if it worked) to do this, and mount per-jail writable fs's for
} appropriatel subdirectories (/etc, /usr/local, /home) with appropriate
} symlinks within the jail.

I badly want nullfs for another reason.  It can be really handy to
allow separate jails to communicate through the filesystem.  Imagine
updating a set of web pages using rsync over ssh in one jail, and
sharing these via a read-only mount in another jail where the web
server is running.


To Unsubscribe: send mail to [e-mail]
with "unsubscribe freebsd-security" in the body of the message

> -------------------------------------------------------------------------- <

發信人: [e-mail] (Geoffrey Robinson), 看板: FB_security
標  題: Re: Jail: Problems? Proper Usage? Status? Practicality?
發信站: NCTU CSIE FreeBSD Server (Thu May 18 14:49:51 2000)
轉信站: Ptt!FreeBSD.csie.NCTU!not-for-mail

On Wed, 17 May 2000, Robert Watson wrote:

> > If a process running in the host system created a UNIX domain socket or
> > named pipe within the jail directory tree. Would a process running in the
> > jail be able to connect to and communicate with the host process through
> > this socket or pipe? If so I guess you could create work around for just
> > about anything by running it on the host system. Would this create a
> > potential way of defeating the jail?
> 
> Jail works by:
> 
> 1) Chrooting the child process
> 2) Limiting the scope of superuser privileges accessible by uid0 processes
>    in the jail
> 
> It does not attempt to prevent processes outside the jail from
> communicating with processes within the jail.  As such, having a process
> do so wouldn't defeat the jail per se, but would defeat the purpose of the
> jail :-).

Still, like any network service the security impact would depend on how
well the server application was written not on the fact you have a link to
the host system. Right?

> I'm not clear on why that would happen -- the libc (etc, etc) in each jail
> should be kept in synch with the kernel, however, and that could be source
> of your problems.  I.e., if you upgrade the kernel, it exports the same
> syscall interface to all processes, regardless of jails, so all jails
> making use of syscalls that have changed need to be upgraded in synch. 
> 
> This is the same as upgrading the kernel without upgrading your normal
> world.
> 
> One way to substantially improve jail scalability would be to allow the
> same (read-only) file system to be present in all jails as the root, with
> only jail-local data being modified.  You can imagine gratuitously using
> nullfs (if it worked) to do this, and mount per-jail writable fs's for
> appropriatel subdirectories (/etc, /usr/local, /home) with appropriate
> symlinks within the jail.  Right now, each jail costs you the size of
> world, and is hard to upgrade if you have any decent number of jails.
> Storing all that stuff in a single tree mapped read-only into jails would
> solve that (you'd probably want two so you could upgrade one, test it, and
> then swap to that for all jails so as to minimize downtime).

If I wanted to do that. Would it be as easy as building a jail on a
spare partition then mounting it read-only to the correct locations?

------------------------------------------------------------------------------
|            Geoffrey Robinson           -          [e-mail]         |
------------------------------------------------------------------------------
                           Random Fortune Quote
"What's another word for Thesaurus?"
		-- Steven Wright




To Unsubscribe: send mail to [e-mail]
with "unsubscribe freebsd-security" in the body of the message

> -------------------------------------------------------------------------- <

發信人: [e-mail] (Robert Watson), 看板: FB_security
標  題: Re: Jail: Problems? Proper Usage? Status? Practicality?
發信站: NCTU CSIE FreeBSD Server (Fri May 19 06:43:18 2000)
轉信站: Ptt!FreeBSD.csie.NCTU!not-for-mail

On Wed, 17 May 2000, Don Lewis wrote:

> On May 16,  1:05pm, Robert Watson wrote:
>
> ...
> 
> } > Finally how secure is jail really? I'm aware of a trivial chroot breakout
> } > technique. Does that hole still exist? Are there any other known holes? Is
> } > jail still under active development? Is it worth the trouble to do any of
> } > this?
> 
> } Right now my efforts are primarily aimed at improving the security
> } abstractions within the kernel relating to the TrustedBSD project--this
> } should have a side benefit of improving the relationship between jail()
> } and the base OS, making Jail easier to maintain and modify.
> 
> I think this is also the right thing to do.  I would go so far as to
> deprecate the jail(2) syscall, and implement jail(8) in terms of
> the syscalls to set up the virtual network interfaces, the syscalls
> to set the process capabilities, and chroot().

I tend to agree.  I'm currently working on a design document for a modular
kernel policy mechanism that would allow pluggable and extendable security
policies, including the capability-limitations associated with Jail.  I
should be posting a first draft to trustedbsd-discuss and freebsd-security
in a couple of days.  This would be distinct from virtualization and
namespace services, but would be responsible for preventing changes to the
virtualization/namespace after it was created and appropriate process
properties were configured.

  Robert N M Watson 

[e-mail]              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services



To Unsubscribe: send mail to [e-mail]
with "unsubscribe freebsd-security" in the body of the message

> -------------------------------------------------------------------------- <

發信人: [e-mail] (Robert Watson), 看板: FB_security
標  題: Re: Jail: Problems? Proper Usage? Status? Practicality?
發信站: NCTU CSIE FreeBSD Server (Fri May 19 08:26:38 2000)
轉信站: Ptt!FreeBSD.csie.NCTU!not-for-mail

On Wed, 17 May 2000, Geoffrey Robinson wrote:

> On Wed, 17 May 2000, Robert Watson wrote:
> 
> > Jail works by:
> > 
> > 1) Chrooting the child process
> > 2) Limiting the scope of superuser privileges accessible by uid0 processes
> >    in the jail
> > 
> > It does not attempt to prevent processes outside the jail from
> > communicating with processes within the jail.  As such, having a process
> > do so wouldn't defeat the jail per se, but would defeat the purpose of the
> > jail :-).
> 
> Still, like any network service the security impact would depend on how
> well the server application was written not on the fact you have a link to
> the host system. Right?

The point of jail() is to limit the scope of compromise, if any, to within
the jail.  As such, the integrity of a jail should rest with the
applications that run in it, but the integrity of the host should not.
I.e., one of the intended environments for jail use is a delegation model
wherein virtual subsystems are provided to
individuals/groups/organizations for their own management.  By virtue of
the jail'd file system being a subset of the host file system,
communication is possible between jails and the host (as well as signal
delivery, et al), but any such communication should have to be initiated
by processes outside the jail, not from within.

> > One way to substantially improve jail scalability would be to allow the
> > same (read-only) file system to be present in all jails as the root, with
> > only jail-local data being modified.  You can imagine gratuitously using
> > nullfs (if it worked) to do this, and mount per-jail writable fs's for
> > appropriatel subdirectories (/etc, /usr/local, /home) with appropriate
> > symlinks within the jail.  Right now, each jail costs you the size of
> > world, and is hard to upgrade if you have any decent number of jails.
> > Storing all that stuff in a single tree mapped read-only into jails would
> > solve that (you'd probably want two so you could upgrade one, test it, and
> > then swap to that for all jails so as to minimize downtime).
> 
> If I wanted to do that. Would it be as easy as building a jail on a
> spare partition then mounting it read-only to the correct locations?

Right now the device handling prevents multiple read-only mounts of the
same partition in multiple places.  This is unfortunate, but I understand
that Poul-Henning Kemp's changes to the bio/device management will address
this, among other things.  That said, it would be more efficient to make
use of some sort of name space translation (assuming our VFS could do it)
as you could allow greater reuse of storage/management resources.  I
assume the buffer cache would be shared between the two in the multi-mount
case, but not the vnodes.  That might also be the case in the namespace
translation instance, so it may be lose-lose in both situations.

  Robert N M Watson 

[e-mail]              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services



To Unsubscribe: send mail to [e-mail]
with "unsubscribe freebsd-security" in the body of the message