From: Thomas Weber (l_vserver_at_mail2news.4t2.com)
Date: Thu 13 Jan 2005 - 16:55:13 GMT
[and this time to the list also]
On Thu, Jan 13, 2005 at 05:12:43PM +0100, Herbert Poetzl wrote:
> > No capability module/support in kernel -> the shutdown scripts inside
> > the vserver shut down all my network interfaces of the whole box.
>
> now the question arises, why do the shutdown scripts
> do that at all?
well, it's the default /etc/init.d/networking stop doing an ifdown -a
on a debian system.
> > So I think the util-vserver package should make sure that there is
> > capability support in the kernel before starting the vserver or else it
> > will silently run insecure vservers!
>
> well, IMHO that is something beyond the scope of
> util-vserver. why? simple, you would encounter the
> same issues on a vanilla system, if you do not load
> or compile in the capability stuff, similar to the
> issues you will encounter if you do not compile in
> support for ipv4, which clearly is _not_ something
> util-vserver should take care of when starting a
> new vserver ...
I don't think it's much diffrent than checking the permissions of
/vservers and giving a warning...
> > this was with 2.6.9+vs1.9.3 and util-vserver 0.30.196
>
> as beforementioned a clean vserver config should not
> touch the hardware (and therefore not take down the
> interfaces) regardless of the capabilities (i.e. the
> admin should have cleaned them up)
even a clean vserver config given away to a customer can end up in an
'unclean' vserver - customer's doing updates or maybe even intentional
writes /etc/init.d/ scripts which will then be run from outside the
vserver by root on the host. And this is something I consider a serious
security problem.
So at least a warning message should be printed!
I don't consider myself a newbie, and I'm running vservers for quite
some time now - this wasn't a know issue to me and it's not very
obvious to figure out. Yet I'm glad this was a problem for me, because
an as you call it 'clean vserver config' would not have triggerd this
behaviour and maybe I would now run totally insecure vservers without
knowing. Maybe there are already lots of insecure vservers up and
running out there.
Tom
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver