From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Mon 22 Sep 2003 - 22:16:19 BST
On Mon, Sep 22, 2003 at 04:29:03PM -0400, Rik van Riel wrote:
> On Mon, 22 Sep 2003, Herbert Poetzl wrote:
> > On Mon, Sep 22, 2003 at 02:53:23PM -0400, Rik van Riel wrote:
> > > I'm wondering how much of the 2.4 vserver infrastructure
> > > is really needed to achieve the same functionality in 2.6.
> >
> > guess we need some central syscall switch, as proposed
> > by yourself, and a nice (working) concept for context
> > creation, manipulation and destruction ...
>
> Or we reuse some other security framework's system call
> for that, if possible.
if appropriate ..
(I have no problem with sharing ;)
> The more code is shared between vserver and the other
> stuff that's already there, the easier it will be to get
> vserver functionality merged.
>
> > > Ideally vserver would be standard functionality and not
> > > a separate fork.
> >
> > agreed, but that is a long way ...
>
> That depends on how big the changes are that vserver
> still needs, on top of the other functionality that's
> already in 2.6 ...
>
> > > For the various components of vserver, I could envision
> > > using these technologies:
> > >
> > > - unbreakable chroot
> > > --> filesystem namespaces, CLONE_NS, recursive bind mount
> > > (already in 2.4 and 2.6 kernels, needs userspace helper)
> >
> > did that some time ago, seemed to work reasonably well,
> > (see http://www.13thfloor.at/VServer/Virtual/)
>
> Cool!
>
> However, I'm not sure you would even need kernel patches for
> this ;)
I neither needed nor used kernel patches for that,
the kernel patches are for creating the virtual contexts ;)
> > > - separated out /proc namespaces
> > > --> cannot be done yet, needs vserver implementation
> > > reuse same implementation for selinux ?
> >
> > maybe separating out some lists will do a major part
> > of the /proc virtualization, /proc/mount can be done
> > with the namespace virtualization, resources should be
> > done by the CKRM, processes will be done by vserver ...
>
> Absolutely. This isn't just a vserver thing, but part of
> something bigger.
but without the notion of contexts, you'll have nothing
to separate on ...
> > > - firewalling, probably IP address binding
> > > --> netfilter & selinux framework
> >
> > I would prefer a virtual network device like that Alex?
> > does, so you can create it from outside, and configure
> > it from inside ... where iptables & co do the security
> > on both sides ...
>
> You're right. It would be better if the root inside the
> vserver could do things to protect the vserver from the
> outside world.
>
> Virtual network device it is ...
>
> > > - cpu & memory resource use of vservers
> > > --> CKRM, see http://ckrm.sourceforge.net/
> >
> > we'll see ...
> > I currently doubt that class and context fit well
>
> Why ?
because the class concept applies to 'groups' of
processes including inheritance, which would fit
verry well, but stops at this level, there seems no
concept for per context info/actions ...
hopefully I'm wrong, and it all works out ...
> > > - network resource use of vservers
> > > --> reuse normal traffic control infrastructure,
> > > maybe selinux infrastructure
> > >
> > > - per-vserver disk quota
> > > --> maybe the selinux people are interested in this too ?
> > > make this something generic, beyond just vserver
> >
> > guess this will not make it into selinux, because the
> > per context tagging of files/dirs is a requirement, but
> > nobody would do that without good reason.
> > same goes for the per context disk limits ...
>
> Even if the selinux people aren't initially interested (I don't
> know if they are, I'll have to ask), that doesn't mean we couldn't
> hook into the selinux framework.
right!
> Remember, if the disk quota stuff is also useful for people who
> aren't using vservers, then there's a better chance of getting
> help from those other people in implementing and merging things.
agreed, but where would you take the context tag info
from, if you do not use contexts ...
> > > Having vserver as small as possible should not only make it
> > > easier to maintain, but also to get it merged upstream.
> >
> > good idea ... 8-)
>
> ;)
best,
Herbert
> Rik
> --
> "Debugging is twice as hard as writing the code in the first place.
> Therefore, if you write the code as cleverly as possible, you are,
> by definition, not smart enough to debug it." - Brian W. Kernighan