Re: [RCF] [PATCH] unprivileged mount/umount

[Jamie Lokier <jamie@shareable.org>]

Miklos Szeredi wrote:
> I also tried bind mounting from the child's namespace to the parent's,
> and that works too.  But the new mount's mnt_namespace is copied from
> the old, which makes the mount un-removable.  This is most likely not
> intentional, IOW a bug.

I agree about the bug (and it's why I think the current->namespace
checks in fs/namespace.c should be killed - the _only_ effect is to
make un-removable mounts like the above, and the checks are completely
redundant for "normal" namespace operations).

I think the best thing to do for "jails" and such is to think of a
private namespace as a collection of bind mounts in a private tree
that (normally) cannot be reached from elsewhere, not can it reach
elsewhere.

And leave it to adminstration to ensure that a tree isn't visible from
another tree if you don't want it to be for security purposes.  That
basically amounts to making sure processes that shouldn't communicate
or ptrace each other can't.

With that view, the kernel's notion of "namespace" is redundant.  It
doesn't add anything to the security model, and it doesn't add any
useful functionality.

It's an abstract idea which does not need to be supported by kernel
code, except for the CLONE_NEWNS operation which actually means "copy
all mounts found recursively starting from the current root) to a new
tree of mounts, and chroot to the new tree".

In other words, is ->mnt_namespace required at all, except to contain
namespace->sem (which could be changed)?  I don't think it adds
anything realistic to security.  The way to make secure jails is to
isolated their trees so they are unreachable.  ->mnt_namespace doesn't
make any difference to that.

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