Re: (pspace,pid) vs true pid virtualization

[Dave Hansen]

On Thu, 2006-02-16 at 20:12 +0100, Herbert Poetzl wrote:
> On Thu, Feb 16, 2006 at 09:41:32AM -0800, Dave Hansen wrote:
> > Giving admin processes the ability to enter pid spaces seems like it
> > solves an entire class of problems, right?. 
> 
> really depends on the situation and the setup.
> let me give a few examples here (I'll assume
> fully blown guests not just pid spaces here)
> 
>  - guest is running some kind of resource hog, 
>    which already reached the given guest limits
> 
>    any attempt to enter the guest will fail
>    because the limits do not permit that
> 
>  - the guest has been suspended (unscheduled)
>    because of some fork bomb running inside
>    and you want to kill off only the bomb
> 
>    entering the guest would immediately stop
>    your process, so no way to send signals
> 
>  - there is a pid killer running inside the
>    guest, which kills every newly created
>    process as soon as it is discovered
> 
>    entering the guest would kill your shell

Brainstorming ... what do you think about having a special init process
inside the child to act as a proxy of sorts?  It is controlled by the
parent vserver/container, and would not be subject to resource limits.
It would not necessarily need to fork in order to kill other processes
inside the vserver (not subject to resource limits).  It could also
continue when the rest of the guest was suspended.

A pid killer would be ineffective against such a process because you
can't kill init.  

> > Could you explain a bit what kinds of security issues it introduces?
> 
> well, it introduces a bunch of issues, not all
> directly security related, here some of them:
> (I keep them general because most of them can
> be worked around by additional checks and flags)
> 
>  - ptrace from inside the context could hijack
>    your 'admin' task and use it for all kind
>    of evil stuff

You can't ptrace init, right?

> In general, I prefer to think of this as working 
> with nuclear material via an actuator from behind 
> a 4" lead wall -- you just do not want to go in 
> to fix things :)

Where does that lead you?  Having a single global pid space which the
admin can see?  Or, does a special set of system calls do it well
enough?

-- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/