In /dev they see very little: full log null ptmx pts random tty urandom zero
The do not have CAP_SYS_MKNOD, so they can't create more than you give.
In fact, the vserver sees whatever you want to give it. So if you intend to run
X in the vserver, give it the mouse device.
> Does /proc/kmem work in virtual servers?
You probably mean /dev/kcore. No they can't read it.
> [Why I'm asking? I'm trying to find ways to take over the machine. Do
> you want to give me root on your machine stating that I can't
> interfere?]
Indeed, I could give you a root password on a vserver and you would not be
able to interfere. Sure enough you would be able to grab resource and slow
down the machine (and potentially work out a DOS attack). We are working
on the schedular right now to solve those issues.
But there is no need to open a crackme vserver. Install it on your machine,
build a vserver. Install the vserver package, reboot a kernel with the patch
with the new new_s_context and set_ipv4root syscall and do
/usr/sbin/vserver test build
enter it and configure a few service
/usr/sbin/vserver test enter
chkconfig crond on
chkconfig sshd on
Then start the server
/usr/sbin/vserver test start
and ssh to it. For now, the build process inherit the user accounts of the
main server, so the root password is the same.
Note that if sshd is already running on the box, you won't be able start
sshd in the test server because sshd on the main server is bound to
0.0.0.0. Just do
/etc/rc.d/init.d/v_sshd restart
or
chkconfig sshd off
chkconfig v_sshd on
> You might want to announce this on bugtraq. [And give solar designer
> root account, he might be more creative ;)].
You don't understand the issue. Anyone can create his own vserver. The
system call controlling this are very simple. It is not a "try to crack my machine"
contest. Anyone can create a vserver and test it.
The security of the vserver is explain on
http://www.solucorp.qc.ca/miscprj/s_context.hc. It relies on the capability
system. So far, I have found one place in the kernel where the capability
was not in place: /proc/sys was changeable if you were root. I added
a capable(CAP_SYS_ADMIN) line to solve this.
--One nice thing about vserver is the clean separation with the real server. For example, after having played with a vserver, if you decide you do not like this concept, then you ca do
reboot the old kernel erase the new kernel rpm -e vserver rm -fr /vservers /etc/vservers
and you are back where you were.
--------------------------------------------------------- Jacques Gelinas <jack@solucorp.qc.ca> vserver: run general purpose virtual servers on one box, full speed! http://www.solucorp.qc.ca/miscprj/s_context.hc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/