Re: RFC [patch 13/34] PID Virtualization Define new task_pid api

[ebiederm@xmission.com (Eric W. Biederman)]

Kirill Korotaev <dev@sw.ru> writes:

>> There areas.
>> 1) Checkpointing.
>> 2) Isolation for security purposes.
>>    There may be secrets that the sysadmin should not have access to.
> I hope you understand, that such things do not make anything
> secure. Administrator of the node will always have access to /proc/kcore,
> devices, KERNEL CODE(!) etc. No security from this point of view.

Only if they have CAP_SYS_RAWIO.  I admit it takes a lot more
to get there than just that.  But having a mechanism that has the
potential to be secured and is much simpler to understand
and to setup for minimal privileges than any of the other unix
addons I have seen is very interesting.


>> 3) Nesting of containers, (so they are general purpose and not special hacks).
> Why are you interested in nesting? Any applications for this?
> Until everything is virtualized in nesting way (including TCP/IP stack, routing
> etc.) I see no much use of it.

For everything except the PID namespace I am just interested in having multiple
separate namespaces.  For the PID namespace to keep the traditional unix
model you need a parent process so it is actually nesting.

I am interested because, it is easy, because if it is possible than
the range of applications you can apply a containers to is much
larger.  At the far end of that spectrum is migrating a server running
on real hardware and bringing it up as a guest on a newer much more
powerful machine.  With the appearance that it had only been
unreachable for a few seconds.

>> The vserver way of solving some of these problems is to provide a way
>> to enter the guest.  I would rather have some explicit operation that puts
>> you into the guest context so there is a single point where we can tackle
>> the nested security issues, than to have hundreds of places we have to
>> look at individually.
> Huh, it sounds too easy. Just imagine that VPS owner has deleted ps, top, kill,
> bash and other tools. You won't be able to enter. 

Entering is different from execing a process on the inside.
Implementation wise it is changing the context pointer on your task.

> Another example when VPS owner
> is near its resource limits - you won't be able to do anything after VPS
> entering.

For debugging this is a good reason for being inside.  What if the
problem is that you are out of resources?  

I have no intention of requiring monitoring to work from the inside though.

> Do you need other examples?

No I need to post patches.

Eric
-
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/