[lkml]   [2001]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subjectre: Re: Announce: many virtual servers on a single box
you mention problems with interaction if the main sandbox has a service
listening on, 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

Mon, 15 Oct 2001, Jacques Gelinas wrote:

> Date: Mon, 15 Oct 2001 09:29:05 -0500
> From: Jacques Gelinas <>
> To: Linux kernel list <>
> Cc: Pavel Machek <>
> 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
> 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
> 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 <>
> vserver: run general purpose virtual servers on one box, full speed!
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to
> More majordomo info at
> Please read the FAQ at
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:08    [W:0.062 / U:0.508 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site