re: Re: Announce: many virtual servers on a single box

[David Lang]

you mention problems with interaction if the main sandbox has a service
listening on 0.0.0.0, what happens if a vserver does this (does it only
see it's own IP addresses or does it interfere with other servers?)

David Lang

 On
Mon, 15 Oct 2001, Jacques Gelinas wrote:

> Date: Mon, 15 Oct 2001 09:29:05 -0500
> From: Jacques Gelinas <[e-mail]>
> To: Linux kernel list <[e-mail]>
> Cc: Pavel Machek <[e-mail]>
> Subject: re: Re: Announce: many virtual servers on a single box
>
> On Fri, 12 Oct 2001 23:01:04 -0500, Pavel Machek wrote
> > Hi!
> >
> > > -I have also modified the capability system a little, so those virtual server
> > >  administrators can't take over the machine. I have introduced a per-process
> > >  capability ceiling, inherited by sub-process. Even setuid program can't grab
> > >  more capabilities..
> >
> > Really? What hardware do they see in /dev/? Do their servers have for
> > example mouse? What about ethernet cards?
>
> 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 <[e-mail]>
> 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 [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>