> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
