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

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: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.

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.

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.

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.