On Wed, 21.01.15 09:49, Daniel J Walsh (dwalsh@xxxxxxxxxx) 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
