F22 System Wide Change: Enable Polyinstantiated /tmp and /var/tmp directories by default

Lennart Poettering mzerqung at 0pointer.de
Wed Jan 21 15:59:44 UTC 2015


On Wed, 21.01.15 09:49, Daniel J Walsh (dwalsh at redhat.com) wrote:

> >> * Other developers:
> >> ** Add /tmp-inst and /var/tmp/tmp-inst to filesystem. (packagename: filesystem)
> >> ** Enable namespaces in /etc/security/namespace.conf (packagename: PAM)
> >> ** Enable proper selinux context and polyinstantiation_enabled boolean to be 
> >> set (packagename: selinux-policy-targeted or selinux-policy)
> > Well, /tmp is used by X11 among other for IPC across user
> > boundaries. If you give each other their private instance of it, they
> > cannot use this for communication anymore. You are breaking X11 this
> > way.
>
> I believe X11 attempts to use the abstract namespace @/tmp/.X11-unix  
> first, at least it used to.

Which is a local DoS vulnerability, since abstract namespace sockets
may be created by anyone, and the names are guessable. X11 really
should stop doing that, it's a security hole.

> > Moreover, if you want to give each user a private instance of /tmp you
> > have to run that user in a private mount namespace and disable
> > propagation from that namespace into the host for the / directory for
> > this. (After all the /tmp over-mounting shall be private to the user,
> > and not propagate to the rest of the system.)  This of course means
> > that if the user later-on invokes /bin/mount or /bin/umount on any
> > subdir of / the commands have will have zero effect for the rest of
> > the system. You pretty much brek mounting/umounting for normal
> > users. If you do this, pretty much every admin will hate you deeply.
>
> There is a way to setup sudo and su to switch back the the hosts
> /tmp, but I agree this would cause confusion.  For example a user
> copies something to /tmp and then tells the admin or another user to
> look at it, and the admin can not see it.

Also the fstab option "users" becomes useless with this scheme.

Lennart

-- 
Lennart Poettering, Red Hat


More information about the devel mailing list