enhance security via private TMP/TMPDIR by default
walters at redhat.com
Thu May 19 18:28:50 UTC 2005
On Thu, 2005-05-19 at 08:04 +0200, Enrico Scholz wrote:
> It will cause lot of problems when two regular sessions have a different
> view of the filesystem. E.g. when session A mounts /media/cdrom, this
> will not be available in session B.
Work is going on on making "shared subtrees" as I think they're called
> Or the /etc/mtab designflaw of 'mount'... it is not NS aware, and although
> it causes other problems e.g. in read-only / it was impossible to eradicate
> it in all the years.
Yeah...that's a can of worms.
> Think of automounting /home/foo: In root-namespace (where the automounter
> was started), nobody accessed this dir and is is not mounted yet.
I think this is essentially the same issue as the first one; if we have
shared subtrees then this should work.
> > noexec's always been virtually useless.
> Why? The '/lib/ld-2... /tmp/foo' trick does not work anymore with recent
That's cool that that hole is closed, although I wonder if there are
other ones. Besides that, there's a few other facets of "useless":
first, that lots of things break on noexec /tmp, and second, you need to
ensure that there aren't any other writable areas that aren't mounted
noexec, and third, SELinux gives you a much more fine-grained control
over execute permissions anyways.
> >> * CLONE_NEWNS + 'mount --bind' are not very well documented and it is
> >> often unclear whether strange behavior is expected or not. E.g. it may
> >> happen that '/' and '/..' are pointing to different inodes; dunno if
> >> this is wanted or not.
> > Hm, so it might confuse tools?
> Yes, it breaks e.g. chroot operations of yum.
Even just for a new /tmp namespace? Seems surprising.
More information about the devel