LinuxQuestions.org - Better than chroot?

I have not tested Vserver, but I'm familiar with another way of placing restrictions on processes using the Grsecurity kernel patches.
If I have a quick glance at the docs I see a Vserver secures its runtime env in 5 area's (and adds 3 nw syscalls as well).
Area:
1. Filesystem: using default chroot() function.
* IMO there's no such thing as something better than chroot, only ways to secure ways chroot is handled.
You should know what the chroot() function does, and what it does not.
When called, chroot accepts an argument which will serve as the new root for the process: chroot(/somedir).
This should be preceded by a chdir(/somedir) to set the current working dir to match the chroot() arg in case the application itself doesn't support it. If a process with root privileges exists in the chroot (say by not dropping privs) a "mkdir out; chroot out; cd .." will get it out.
Other ways to get out of a chroot are pivot_root() (chroot inside a chroot), capget (leech privs from process outside chroot), fchdir (using a file descriptor of the chrooting process) and chmod (get setgid or setuid).
W/o reading the code I can not tell these issues (and other chroot restrictions) are addressed in Vserver like they are in Grsecurity.

2. Processes: using new function new_s_context to "shield" processes from "viewing" processes outside it's context
* Quite different from what GRsecurity does because it allows for a process to view other processes info when they are in the same "group".
GRsecurity can shield off /proc to have users view only their process information. Looking at the fchdir() stuff under chroot, you could argue if even loading /proc inside a chroot is a Good Thing.

3. Networking: using new function set_ipv4root to "chroot" processes to their network address
* Not even close. GRsecurity doesn't have this.

4. Super user capabilities: using LINUX_CAPABILITIES (caps intended)
* You could do this with some utilities w/o need for Vserver or GRsecurity. Beware tho, if you take away the right caps from root you won't even be able to reboot :-]
5. System V IPC shm selection using new_s_context.
* GRsecurity doesn't have this. It does incorporate a patch for making /dev/kmem read-only, and PAX to have some form of buffer overflow protection. This seems to break XFree86 4, Wine and the java runtime tho, the first 2 you don't need on a server and java, uh, well, isn't java way slow anyway? :-]

I'm not trying to pass the above off as an objective view on things and I'm not about to wrongly discredit Vserver, but you should know there's more than one way to make chroot behave better, more secure.

If you haven't already, read some of the refs below to make sure you know the do and don'ts like mounting proc, allowing symlinks to outside the chroot and allowing suetuid/setgid binaries:
How to break out of a chroot() jail, Simes 12 05 2002: http://www.bpfh.net/simes/computing/chroot-break.html, Using Chroot Securely, Anton Chuvakin, 10 02 2002: http://www.linuxsecurity.com/feature..._story-99.html and Silvio's doc at http://www.big.net.au/~silvio/runtim...m-patching.txt (he's got more interesting stuff around).

As a chroot shell I use Jail because it allows me to set up the basic skeleton for a jail relatively easy, so I only have to worry about tweaking like dir/file permissions and conf files. If I need to provide a login and shell, I'll use a modified Busybox binary with symlinks tweaked for that env, and sash if necessary.

HTH, and if I'm wrong somewhere anyone please correct me.