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

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

[Jacques Gelinas]

On Mon, 15 Oct 2001 17:22:43 -0500, James Sutherland wrote

> > But there is no need to open a crackme vserver. Install it on your machine,
> > build a vserver.
>
> The question, I think, was would YOU give out root access on vservers on
> YOUR box, and be confident people wouldn't be able to escape? :-)

Yes this is the goal. At the office we have many developpers doing various
projects. They often have to setup special demos and those demos must be
located in our dmz. So until now, we could not give them root password. This
was kind of annoying (It is always annoying to refuse the root password to
a friend). Now we can do it.

But I suspect many ASP will use this. For now to make the box really robust
we need to enhance the schedular (some fairness) and make the user
resource global to a vserver. For now, you can limit a process (ulimit) and the
number of process a user can start, but you have little control over total
limits used by a user or vserver (right ?, maybe 2.4 has something in this area
I have missed)

> > > 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.
>
> But can you crack your way OUT of the vserver - how confident are you in
> the isolation provided?

Highly. Bug pending.

The concept is both very simple and sound


	security ID to isolate processes (an integer)

	chroot to isolate the files

	capabilities to lower the ability of root (I had to enhance that
	a little with the capability ceiling)

	set_ipv4root to tie all processes in a vserver to one IP.

The "bug pending" means that I may have forgotten one place in the kernel.
For example, when I implemented the new_s_context, I patchs the kill system
call in few places, then later I realized the ptrace syscall was an issue. I added
a one line test there. I may have forgotten one check.

The same applies to capabilities. When we moved from suser() to capable() we may
have forgotten something. Since capabilities are not that much used, some place
may be missing. For example /proc/sys was writtable by root and not protected
by any capabilities.

But the changes in the kernel a trivial. This is why I am posting here to
get some review.

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

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

[Riley Williams]

Hi Jacques.

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

>> But can you crack your way OUT of the vserver - how confident are you
>> in the isolation provided?

> Highly. Bug pending.

> The concept is both very simple and sound

...

> 	set_ipv4root to tie all processes in a vserver to one IP.

How well does this work on an ipv6 only box?

Best wishes from Riley.

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

[Jacques Gelinas]

On Mon, 15 Oct 2001 08:55:51 -0500, David Lang wrote
> 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?)

The vserver can't bind 0.0.0.0. The new set_ipv4root system call (named
after the chroot one) is setting one IP number in the current task_struct.
the system call accept only a transition from 0 to some IP. So like chroot()
once you do it in a process you are trapped.

The system calls affects both the bind() syscall and the connect() one (when
it lookup the route). Once an ipv4 root is set to x.y.z.w, the process (and children) can
do

	bind (0.0.0.0) and it gets bind(x.y.z.w)
	connect() without binding and they get coonect + bind(x.y.z.w)
	bind (x.y.z.w) and it gets bind(x.y.z.w)
	bind(another_ip) and it gets an error
	connect + bind(another_IP) and it gets an error.

The ability to bind multiple time on a port has always been there. So using
this call, we limit the vserver to a single IP. The nice part is that this is
completly transparent to the vserver services. Services like apache, sshd, xinetd
sybase are running without any special configuration.

Btw, the v_xxx service (v_httpd, v_sshd) are simple wrapper to run service
in the main server without having to change their configuration so they
do not interfere. What they do is simply

	#!/bin/sh
	/usr/sbin/chbind --ip eth0 /etc/rc.d/init.d/httpd $*

Also you can do the following

	/usr/sbin/chbind --ip 1.2.3.4 some_command

and this effectivly prevent the "some_command" to do any IP network activity.
The set_ipv4root() syscall is not privileged at all. Its a one shot thing though :-)

--

For now, I have not tried to hide completly the fact that a vserver is a vserver.
The only feature it has is that a vserver can have its own host and domain name.
This was done because many service use this to setup some defaults and I wanted
vservers to be as natural as possible configuration wise.

I could have added a couple featurism such as

	private uptime
	hide the network device and fake a single one
	what else.

We will see as the need arise.

I also added the /sbin/vreboot command which talks with a socket /dev/reboot
established by the rebootmgr service in the root server (one socket per
vserver). This way a vserver can test its ability to properly shutdown and start.
The reboot manager simply does

	/usr/sbin/vserver the-vserver restart

this simply chroot to the vserver, selec the same security context, sets
the ipv4root and then exec

	/etc/rc.d/rc 6

Then it kills the remaining processes. To start it, it executes

	/etc/rc.d/rc 3

In general, you reboot a vserver in 3 seconds :-)

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