FreeBSD Jails

BSD Forums writes "A common security breach involves exploiting one application to gain access to another. Keeping separate applications separate can limit the potential damage. OnLamp's Mike DeGraw-Bertsch explains how FreeBSD's jails can help secure necessary applications."

Comments

sandbox

[Hard_Code]

Instead of this adhoc-ish system, wouldn't a better solution be to have a "correct" sandbox in which a policy can be attached to ANY process, which determined what kernel calls can be made, and potentially with what parameters? Then there is no need for wacky interface aliasing and stuff like that.

Re:sandbox

[ctr2sprt]

No, not really. The problem with all these fine-grained access controls is that they are painfully difficult to use. Unix admins get worked up about the complexity introduced by simple POSIX filesystem ACLs, how do you think they'll be able to tolerate having per-process syscall control? It would just never get used. Incidentally, they are patches which allow exactly the functionality you describe. And nobody uses them except for people with a really exceptional need for security.

Jails have other uses too, by the way. Website hosting is one such example. You can set up jails for each person using the machine, and then he gets his own root login. He can modify Apache config files himself and do any other configuration stuff, but he can't break out of the jail to interfere with other users. There are actually providers out there that do this, though I don't know any of them by name.

Re:sandbox

[delfstrom]

There are actually providers out there that do this, though I don't know any of them by name

JohnCompanies is one such host that uses FreeBSD jails to give you your own root and ports tree.

Jails addons

[rf0]

For some fun jail patches have a look at garage.freebsd.pl

Rus

systrace

[bikepunk]

check out OpenBSD's systrace:
http://www.citi.umich.edu/u/provos/systrace/
http://www.openbsd.org/cgi-bin/man.cgi?query=systr ace&apropos=0&sektion=0&manpath=OpenBSD+Current&ar ch=i386&format=html

Re:bind?

[m0rten]

And better alternatives exist - like qmail and djbdns. Is there any reason to run those pieces of shit besides legacy config files?

To quote the Makefile for /usr/ports/mail/qmail:

NO_PACKAGE= djb's packaging license does not allow non-standard qmail binary distributions

I would guess this is a big showstopper for using qmail in the FreeBSD basesystem. However, I think it was recently added some glue to sysinstall to let you choose MTA during install.

Re:bind?

[xA40D]

And better alternatives exist

In your opinion. Personally I dislike sendmail, but love BIND (just don't run it as root). But then I dislike qmail as much as sendmail, and djbdns strikes me as mildly braindamaged - so I'd hate to see them installed by default.

An ideal system would have the entire OS as packages... then all you need to do in to install your favourites....

nore on jails

[nerdsv650]

Nice intro. I've been running jails on FreeBSD for some time now, here are some additional notes I put together some time back.

http://www.xyz.com/notes/jailnotes.html

Hope this helps someone.

-michael

pity they can't have private namespaces

[F2F]

we have them in Plan 9. and they've been there for the past 14 years -- each user, each process, each device exists in its own namespace and views the system differently.

my / != your /

after years and years of trying maybe it's time you guys really do something about it -- jails are a temporary solution, and not a very good one at that.

you need full private namespaces for the same reason you need local variables in your programs -- it's just too nasty otherwise.

Re:pity they can't have private namespaces

[cperciva]

DragonFlyBSD is supposed to be getting something like this; each process only sees its own version of shared libraries.

Go directly to jail.

[yerricde]

Does Linux offer something similar [to chroot jails]?

Linux has a chroot jail.

SCO has the other kind of jail too, unless you pay $699 to Darl McBribe [sic].

My jailadmin stuff...

[Just Some Guy]

I wrote (in Perl) a set of jail management scripts. They're available at SubWiki:Freebsd/JailAdmin.

The main feature is a configuration that lets you act on jails by name. For instance:

jailadmin start web3 news7 shell1 shell2

will start those jails, and

jailadmin stop shell4

will stop that instance. Basically, I wanted to make a system that was convenient for people with large numbers of jails on one machine, but easy enough for everyone.

Included are an rc.d script for starting/stopping a set of jails at boot/shutdown, and an snmpd plugin for remote monitoring.

Re:Does Linux offer something like this?

[Anonymous Coward]

Actually, UML is not a supermaximum, it may be considered a supermaximum chroot, but in fact, it's much worse than the FreeBSD jail functionality.

1. For each UML you have another kernel stealing memory, FreeBSD just uses one kernel.

2. UML uses loopback on fs, which is really really slow, it also means that if you have multilevel "jails" you soon get practically zero performance; with FreeBSD this does not happen.

In all fairness, UML is great if you want to test your programs for a multitude of different kernels on the same machine, but for everything else the FreeBSD jail is superior.

So in the end, if you play with kernels the UML is really great and FreeBSD *should* consider offer something similar. For real world use jail is the thing.