sys_vserver

sys_vserver

[Chris Wright]

I'm surprised to see this merged, even as a place holder.  Primarily
because the same approach was soundly rejected for LSM and sys_security.

  For 2.6 I'd like to do things right.  At the moment the vserver patch
  has sys_new_s_context and sys_set_ipv4root calls, but since we'll
  probably end up getting an ipv6 call too and people are planning future
  functionality, I guess it would be more appropriate to multiplex these
  through one sys_vserver patch, in the same way sys_ipc works.

Multiplexing, future functionality, etc...this reasoning was shot down
before.   The preferred method was to have well-typed interfaces that 
are simple and not overloaded.  Any chance some of these needs could be
met with existing infrastructure in 2.6?  For example, similar to the
sys_new_s_context issue was resolved for LSM with the /proc/pid/attr/
interface, could this be reused?

I'm not trying to instigate a flame, just understand where this is
going.  Sorry if I missed the discussion already.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: sys_vserver

[Rik van Riel]

On Wed, 1 Oct 2003, Chris Wright wrote:

> Multiplexing, future functionality, etc...this reasoning was shot down
> before. The preferred method was to have well-typed interfaces that 
> are simple and not overloaded.  Any chance some of these needs could be
> met with existing infrastructure in 2.6?  For example, similar to the
> sys_new_s_context issue was resolved for LSM with the /proc/pid/attr/
> interface, could this be reused?

OK, a few comments here:

1) the vserver functionality definately is not "future functionality",
   people have been using it in production for a few years already

2) currently vserver only runs on 2.4 (and I think 2.2), it hasn't
   been ported to 2.6 yet and I definately plan to port it in such
   a way that we will be reusing other infrastructure whereever
   possible ... it's just that vserver needs some infrastructure
   that is not possible inside LSM

3) the needs that can be met with existing infrastructure, like
   CLONE_NEWNS or LSM should definately move out of the vserver
   patch in the port to 2.6

4) I'm all for generalising the interface, how about sys_virtual_context ?

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

Re: sys_vserver

[Chris Wright]

* Rik van Riel (riel@redhat.com) wrote:
> On Wed, 1 Oct 2003, Chris Wright wrote:
> 
> > Multiplexing, future functionality, etc...this reasoning was shot down
> > before. The preferred method was to have well-typed interfaces that 
> > are simple and not overloaded.  Any chance some of these needs could be
> > met with existing infrastructure in 2.6?  For example, similar to the
> > sys_new_s_context issue was resolved for LSM with the /proc/pid/attr/
> > interface, could this be reused?
> 
> OK, a few comments here:
> 
> 1) the vserver functionality definately is not "future functionality",
>    people have been using it in production for a few years already

Sorry, I don't mean to imply core vserver is all new, just reacting to
one of the justifciations being "people are planning future
functionality."

> 2) currently vserver only runs on 2.4 (and I think 2.2), it hasn't
>    been ported to 2.6 yet and I definately plan to port it in such
>    a way that we will be reusing other infrastructure whereever
>    possible ... it's just that vserver needs some infrastructure
>    that is not possible inside LSM
> 
> 3) the needs that can be met with existing infrastructure, like
>    CLONE_NEWNS or LSM should definately move out of the vserver
>    patch in the port to 2.6

Glad to hear it.  I haven't looked closely at vserver since about 2.4.14,
but I had hoped to find ways to minimize the vserver patch by reusing
some of the LSM infrastructure.  The biggest issue was the ability to
virtualize the results of something like the hostname to be ctx
specific, which was deemed too much to do for the LSM interfaces.

> 4) I'm all for generalising the interface, how about sys_virtual_context ?

I _think_ this can be done with /proc/[pid]/attr/.  This allows you to
set the security attributes of a process.  IIRC, the sys_s_new_context
was something helpers would run before execve'ing a process into the new
context (sorry if my details are off).  Same can be acheived with
/proc/[pid]/attr/exec, but writing the new context to that file, then
execve'ing.  Here's a link with more details on the API:

http://mail.wirex.com/pipermail/linux-security-module/2003-April/4264.html       
thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: sys_vserver

[Rik van Riel]

On Wed, 1 Oct 2003, Chris Wright wrote:

> > 3) the needs that can be met with existing infrastructure, like
> >    CLONE_NEWNS or LSM should definately move out of the vserver
> >    patch in the port to 2.6
> 
> Glad to hear it.  I haven't looked closely at vserver since about 2.4.14,
> but I had hoped to find ways to minimize the vserver patch by reusing
> some of the LSM infrastructure. 

That is my biggest issue, too.  I really want vserver, but
I don't want to carry around a patch that's any larger than
it needs to be ;)

> The biggest issue was the ability to virtualize the results of something
> like the hostname to be ctx specific, which was deemed too much to do
> for the LSM interfaces.

Yup, that is indeed too much for the LSM interface;  because
of that additional things would seem needed.

> > 4) I'm all for generalising the interface, how about sys_virtual_context ?
> 
> I _think_ this can be done with /proc/[pid]/attr/.  This allows you to
> set the security attributes of a process. 

> http://mail.wirex.com/pipermail/linux-security-module/2003-April/4264.html       

Ohhhhhh.  I will need to check this out.  Thanks for the
information.  I've asked some selinux people whether there
was functionality like this and they didn't think so. Good
to see there is something after all ;)

I'll look at this in more detail to see whether it would
be enough to implement virtual host functionality.

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

Re: sys_vserver

[Herbert Poetzl]

On Wed, Oct 01, 2003 at 12:15:36PM -0700, Chris Wright wrote:
> * Rik van Riel (riel@redhat.com) wrote:
> > On Wed, 1 Oct 2003, Chris Wright wrote:
> > 
> > > Multiplexing, future functionality, etc...this reasoning was shot down
> > > before. The preferred method was to have well-typed interfaces that 
> > > are simple and not overloaded.  Any chance some of these needs could be
> > > met with existing infrastructure in 2.6?  For example, similar to the
> > > sys_new_s_context issue was resolved for LSM with the /proc/pid/attr/
> > > interface, could this be reused?
> > 
> > OK, a few comments here:
> > 
> > 1) the vserver functionality definately is not "future functionality",
> >    people have been using it in production for a few years already
> 
> Sorry, I don't mean to imply core vserver is all new, just reacting to
> one of the justifciations being "people are planning future
> functionality."
> 
> > 2) currently vserver only runs on 2.4 (and I think 2.2), it hasn't
> >    been ported to 2.6 yet and I definately plan to port it in such
> >    a way that we will be reusing other infrastructure whereever
> >    possible ... it's just that vserver needs some infrastructure
> >    that is not possible inside LSM
> > 
> > 3) the needs that can be met with existing infrastructure, like
> >    CLONE_NEWNS or LSM should definately move out of the vserver
> >    patch in the port to 2.6
> 
> Glad to hear it.  I haven't looked closely at vserver since about 2.4.14,
> but I had hoped to find ways to minimize the vserver patch by reusing
> some of the LSM infrastructure.  The biggest issue was the ability to
> virtualize the results of something like the hostname to be ctx
> specific, which was deemed too much to do for the LSM interfaces.
> 
> > 4) I'm all for generalising the interface, how about sys_virtual_context ?
> 
> I _think_ this can be done with /proc/[pid]/attr/.  This allows you to
> set the security attributes of a process.  IIRC, the sys_s_new_context
> was something helpers would run before execve'ing a process into the new
> context (sorry if my details are off).  Same can be acheived with
> /proc/[pid]/attr/exec, but writing the new context to that file, then
> execve'ing.  Here's a link with more details on the API:

one of the advantages the current _and_ future vserver project
has over 'changing/setting some features for a process' is the
concept of a context layer, residing between kernel and processes
_belonging_ to a context ...

you could, for example set up a context which allows a maximum
of 10 processes, limited to one ethernet interface, using it's
own root/user quota, start some 'virtual' server in this context
doing all this init stuff, and then visit this context from
outside, via a simple 'context' change ... if you've got the
right capabilities/permissions ...

I can not imagine how you would do that with the /proc/<pid>/attr/
interface, but I'm sure you can explain it to me ...

best,
Herbert

> http://mail.wirex.com/pipermail/linux-security-module/2003-April/4264.html       
> thanks,
> -chris
> -- 
> Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net
> -
> 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: sys_vserver

[Chris Wright]

* Herbert Poetzl (herbert@13thfloor.at) wrote:
> 
> one of the advantages the current _and_ future vserver project
> has over 'changing/setting some features for a process' is the
> concept of a context layer, residing between kernel and processes
> _belonging_ to a context ...

Yes, I agree, this is a useful abstraction.

> you could, for example set up a context which allows a maximum
> of 10 processes, limited to one ethernet interface, using it's
> own root/user quota, start some 'virtual' server in this context
> doing all this init stuff, and then visit this context from
> outside, via a simple 'context' change ... if you've got the
> right capabilities/permissions ...
> 
> I can not imagine how you would do that with the /proc/<pid>/attr/
> interface, but I'm sure you can explain it to me ...

Put it this way, typical security modules have a notion of a
context, and the ability to grant/deny actions base on the context.
The /proc/<pid>/attr interface is how you can set/retrieve the context
per process, and subsequent fork/exec's can chose how to propagate
that context.  I believe a reasonable portion of vserver can become a
security module, but there would clearly remain a need for some of the
virtualization (e.g. hostname, etc.).

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: sys_vserver

[Rik van Riel]

On Wed, 1 Oct 2003, Chris Wright wrote:

> I believe a reasonable portion of vserver can become a security module,
> but there would clearly remain a need for some of the virtualization
> (e.g. hostname, etc.).

I definately want to have as much as possible of vserver
using the normal security infrastructure, simply because
it will save the vserver maintainers a lot of work ;)

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

Re: sys_vserver

[James Morris]

On Wed, 1 Oct 2003, Rik van Riel wrote:

> On Wed, 1 Oct 2003, Chris Wright wrote:
> 
> > I believe a reasonable portion of vserver can become a security module,
> > but there would clearly remain a need for some of the virtualization
> > (e.g. hostname, etc.).
> 
> I definately want to have as much as possible of vserver
> using the normal security infrastructure, simply because
> it will save the vserver maintainers a lot of work ;)
> 

I think virtualization is important/useful enough to warrant an API of
it's own.  It could be similar to LSM, e.g.  allow pluggable
virtualization modules, with no cost for the base kernel.



- James
-- 
James Morris
<jmorris@redhat.com>

Re: sys_vserver

[Chris Wright]

* James Morris (jmorris@redhat.com) wrote:
> I think virtualization is important/useful enough to warrant an API of
> it's own.  It could be similar to LSM, e.g.  allow pluggable
> virtualization modules, with no cost for the base kernel.

Doesn't sound like 2.6 material.

Re: sys_vserver

[Rik van Riel]

On Wed, 1 Oct 2003, Chris Wright wrote:
> * James Morris (jmorris@redhat.com) wrote:
> > I think virtualization is important/useful enough to warrant an API of
> > it's own.  It could be similar to LSM, e.g.  allow pluggable
> > virtualization modules, with no cost for the base kernel.
> 
> Doesn't sound like 2.6 material.

Maybe not, but it does sound like something we want to be
ready by the time 2.7 is forked ;)

Also, some parts of the virtualisation code might be 2.6
material after all, depending on how simple/complex the
code in question is.

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

Re: sys_vserver

[Chris Wright]

* Rik van Riel (riel@redhat.com) wrote:
> On Wed, 1 Oct 2003, Chris Wright wrote:
> > * James Morris (jmorris@redhat.com) wrote:
> > > I think virtualization is important/useful enough to warrant an API of
> > > it's own.  It could be similar to LSM, e.g.  allow pluggable
> > > virtualization modules, with no cost for the base kernel.
> > 
> > Doesn't sound like 2.6 material.
> 
> Maybe not, but it does sound like something we want to be
> ready by the time 2.7 is forked ;)

Yes, good point ;-)  And I do agree it's a useful concept.
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: sys_vserver

[Linus Torvalds]

On Wed, 1 Oct 2003, Chris Wright wrote:
> 
> Doesn't sound like 2.6 material.

Agreed. I know virtualization is fairly high up on the list of things that
people ask for, and some people actually end up using UML for that. But 
right now it's just a system call number placeholder, not something that 
will go in. 

And I suspect you'll find a number of vendors who start integrating
patches into their "server release" thing if there truly is enough
pressure from users. Which is fine.

		Linus

Re: sys_vserver

[Rik van Riel]

On Wed, 1 Oct 2003, Linus Torvalds wrote:

> And I suspect you'll find a number of vendors who start integrating
> patches into their "server release" thing if there truly is enough
> pressure from users. Which is fine.

Actual use will also help determine exactly what functionality
should be merged into 2.7 and what wasn't really needed.

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

Re: [vserver] Re: sys_vserver

[Herbert Poetzl]

On Wed, Oct 01, 2003 at 02:16:54PM -0700, Chris Wright wrote:
> * Herbert Poetzl (herbert@13thfloor.at) wrote:
> > 
> > one of the advantages the current _and_ future vserver project
> > has over 'changing/setting some features for a process' is the
> > concept of a context layer, residing between kernel and processes
> > _belonging_ to a context ...
> 
> Yes, I agree, this is a useful abstraction.
> 
> > you could, for example set up a context which allows a maximum
> > of 10 processes, limited to one ethernet interface, using it's
> > own root/user quota, start some 'virtual' server in this context
> > doing all this init stuff, and then visit this context from
> > outside, via a simple 'context' change ... if you've got the
> > right capabilities/permissions ...
> > 
> > I can not imagine how you would do that with the /proc/<pid>/attr/
> > interface, but I'm sure you can explain it to me ...
> 
> Put it this way, typical security modules have a notion of a
> context, and the ability to grant/deny actions base on the context.
> The /proc/<pid>/attr interface is how you can set/retrieve the context
> per process, and subsequent fork/exec's can chose how to propagate
> that context.  I believe a reasonable portion of vserver can become a
> security module, but there would clearly remain a need for some of the
> virtualization (e.g. hostname, etc.).

hmm, okay I see it now clearly, we should take
the approach which was so successful for scsi ...

echo "vserver add-new-vserver 100 0 1 192 0 0 1" >/proc/1/attr/new

and of course to 'change' the context, a simple

echo "vserver change-to-old-context 100" >/proc/self/attr/migrate
(and it was never seen again, because it vanished in context 100)

will be sufficient ...

seriously I am completely on your side if we talk about
limiting a process or changing it's environment, even
if we talk about setting a class assignment, but I just 
don't believe it's the perfect solution for everything ...

best,
Herbert

> thanks,
> -chris
> -- 
> Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: [vserver] Re: sys_vserver

[Chris Wright]

* Herbert Poetzl (herbert@13thfloor.at) wrote:
> 
> hmm, okay I see it now clearly, we should take
> the approach which was so successful for scsi ...
> 
> echo "vserver add-new-vserver 100 0 1 192 0 0 1" >/proc/1/attr/new
> 
> and of course to 'change' the context, a simple
> 
> echo "vserver change-to-old-context 100" >/proc/self/attr/migrate
> (and it was never seen again, because it vanished in context 100)
> 
> will be sufficient ...

Sorry if I don't follow your example correctly.  There is an attr/prev
as well as attr/current, if you are worried the previous context would
be lost.

> seriously I am completely on your side if we talk about
> limiting a process or changing it's environment, even
> if we talk about setting a class assignment, but I just 
> don't believe it's the perfect solution for everything ...

Yes, I agree, it won't be useful for everything, but where
possible/sensible, we should reuse it.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net