enhance security via private TMP/TMPDIR by default

Colin Walters 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
working upstream.

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

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 mailing list