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

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

[Jacques Gelinas]

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 <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: 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 <jack@solucorp.qc.ca>
> To: Linux kernel list <linux-kernel@vger.kernel.org>
> Cc: Pavel Machek <pavel@suse.cz>
> 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 <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/
>

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

[James Sutherland]

On Mon, 15 Oct 2001, Jacques Gelinas wrote:
> 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.

Hmmm - does this work with devfs?

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

Have you looked at the "fairsched" patch for this? It seems to be
unmaintained since 2.4.0-testXX, but look close to your needs...

> 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? :-)

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


James.
-- 
"Our attitude with TCP/IP is, `Hey, we'll do it, but don't make a big
system, because we can't fix it if it breaks -- nobody can.'"

"TCP/IP is OK if you've got a little informal club, and it doesn't make
any difference if it takes a while to fix it."
		-- Ken Olson, in Digital News, 1988

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

[James Sutherland]

On Mon, 15 Oct 2001, 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?)

It only sees its own IP address(es). If one vserver could interfere with
another like that, this would be rather a big hole in the vserver
isolation :)


James.

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

[Pavel Machek]

Hi!

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

Yep. I know that. But I'm not going to install my own vserver. (Too
much work ;-). I might crack yours, OTOH ;-).
								Pavel
-- 
STOP THE WAR! Someone killed innocent Americans. That does not give
U.S. right to kill people in Afganistan.