lkml.org 
[lkml]   [2006]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: RFC [patch 13/34] PID Virtualization Define new task_pid api
From
Date
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/

\
 
 \ /
  Last update: 2006-02-02 17:32    [W:0.195 / U:0.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site