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

[Miklos Szeredi <miklos@szeredi.hu>]

> 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.

I'm not sure. 

> It doesn't add anything to the security model, and it doesn't add
> any useful functionality.

Struct namespace is pretty small, so let's see:

  1) count:  reference count for the "tree"

     if you remove this, how will you know when to "unmount" the tree?

  2) root: the root of the tree

     needed for the unmount, when the namespace has no more references

  3) list: flat list of mounts in the tree

     used by /proc/PID/mounts, but probably not strictly needed

  4) sem:  protects the mount list and the tree from modification

     could be removed in favor of a global lock, but that would
     increase contention

> 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.

Probably true.  check_mnt() is there to make sure only trees protected
by namespace->sem are modified, and is not a security check.  That is
why the recursive bind mount from foreign namespace is not allowed,
while the simple bind mount is.

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