lkml.org 
[lkml]   [2005]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RCF] [PATCH] unprivileged mount/umount
From
Date
> 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/

\
 
 \ /
  Last update: 2005-05-13 10:59    [W:0.134 / U:1.212 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site