From: Ivo De Decker (ivo_at_zeus.rug.ac.be)
Date: Sun 01 Dec 2002 - 20:55:15 GMT
On Sun, Dec 01, 2002 at 02:36:28AM +0100, Sascha Silbe wrote:
> Note that the new system calls (new_s_context and set_ipv4root) are not
> controlled by capabilities. They are by nature irreversible. Once a virtual
> server is trapped in a chroot/s_context/ipv4root box, it can't escape from
> the parameters of this trap.
>
>
> asmlinkage int sys_set_ipv4root (__u32 ip[], int nbip, __u32 bcast)
> {
> [...]
> }else if (ip_info == NULL
> || ip_info->ipv4[0] == 0
> || capable(CAP_NET_ADMIN)){
> // We are allowed to change everything
> ret = 0;
>
> So the docu says no capability enables one to break out of ipv4root, but the
> source suggests otherwise.
> Am I missing some important fact or is it a mismatch between theory and
> practice?
Well, you're not really correct:
set_ipv4root is reversible: it's very easy to call it again, and change the
ipv4root. However, you do need CAP_SYS_ADMIN to change the ipv4root. If you
don't have CAP_SYS_ADMIN you can only reduce the ipv4root to a subset of the
current ipv4root. (I don't think this is documented in capability.h)
This isn't really a problem inside a vserver, because CAP_SYS_ADMIN is removed
when the vserver is started.
new_s_context is irreversible. However, it is possible to create a new
security context from inside another security context if it is not created
with the 'lock' flag (this is documented in the default vserver.conf; vserver
sets the lock flag by default).
If I'm not mistaken, all resource limitations are inherited by this new
vserver.
To change to an exisiting security context, you need to be in context 0, and
have CAP_SYS_ADMIN (this is (partially) documented in capability.h).
I hope this is an answer to your question.
Greetings,
Ivo De Decker