On Tue, 20.01.15 12:53, Jaroslav Reznik (jreznik@xxxxxxxxxx) wrote: > = Proposed System Wide Change: Enable Polyinstantiated /tmp and /var/tmp > directories by default = > https://fedoraproject.org/wiki/Changes/Polyinstantiated_tmp_by_Default > > Change owner(s): Huzaifa Sidhpurwala <huzaifas@xxxxxxxxxx> > > Polyinstantiation of temperary directories is a pro-active security measure, > which reduced chances of attacks caused due to the /tmp and /var/tmp > directories being world-writable. These include flaws caused by predictive > temp. file names, race conditions due to symbolic links etc. > > == Detailed Description == > The basic idea is to provide better security to Fedora installs. Though > Polyinstantiated /tmp has worked since Fedora 19, its not a single step > process to configure it. Secondly people don't really understand its benefits. > Because of this having it on by default makes more sense. It is completely > transparent to the user, they wont even realize that it has been enabled. > > The Red Hat Product Security Team assigns CWE ids to severe flaws (CVSSv2 > 7). > Here is a list of severe flaws caused by insecure tmp files [1]. > > == Scope == > * Proposal owners: No work required to be done by proposal owner. > > * 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. 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. Also, introducing "/tmp-inst" sounds really wrong to me, what's the point of that? systemd's PrivateTmp= works by mounting /tmp over with a subdir of /tmp, so that things stay on the same file system. Why introduce a new directory? How do you intend for the new /tmp instance to be life-cycled? When is the private /tmp instance removed? On logout? Tracking a user session's lifecycle is not easy, as the user might have processes running that are not attached to any session, and you shouldn't remove the private /tmp before those processes are dead too. To me this sounds very much not thought to the end. We thought a couple of times in adding an option for this to systemd/logind, after all, we have the namespacing code in systemd anyway, and we can at least track the sessions through logind very precisely. However, X11 and the mount propagation breakage are real blockers to make this useful in the general case. This idea can only fly for very special systems where the propagation is irrelevant. It's not compatible with admin workflows, at all. 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
