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.There areas. 1) Checkpointing. 2) Isolation for security purposes. There may be secrets that the sysadmin should not have access to.
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.
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. Another example when VPS owner is near its resource limits - you won't be able to do anything after VPS entering.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.
Do you need other examples? Kirill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: [email protected] (Eric W. Biederman)
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- References:
- RFC [patch 00/34] PID Virtualization Overview
- From: Serge Hallyn <[email protected]>
- RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: Serge Hallyn <[email protected]>
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: Arjan van de Ven <[email protected]>
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: "Serge E. Hallyn" <[email protected]>
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: Alan Cox <[email protected]>
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: Dave Hansen <[email protected]>
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: Greg KH <[email protected]>
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: Dave Hansen <[email protected]>
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: [email protected] (Eric W. Biederman)
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: Hubertus Franke <[email protected]>
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: Linus Torvalds <[email protected]>
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: Kirill Korotaev <[email protected]>
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: [email protected] (Eric W. Biederman)
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: Kirill Korotaev <[email protected]>
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: [email protected] (Eric W. Biederman)
- RFC [patch 00/34] PID Virtualization Overview
- Prev by Date: lsserio
- Next by Date: Re: GPL V3 and Linux - Dead Copyright Holders
- Previous by thread: Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- Next by thread: Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- Index(es):