On 01/20/2015 07:29 AM, Lennart Poettering wrote: > On Tue, 20.01.15 12:53, Jaroslav Reznik (jrez...@redhat.com) 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 <huzai...@redhat.com> >> >> 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. I believe X11 attempts to use the abstract namespace @/tmp/.X11-unix first, at least it used to.
> 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, 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? I agree this should be a subdir of the hosts /tmp. > 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 > I agree. Although it would be nice is there was a simple command to turn this on, and then we could have users actually try it out. It is very nice for multi user systems, where the users are not really trustworthy. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
