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

[Lennart Poettering]

On Tue, 20.01.15 12:53, Jaroslav Reznik (jreznik at 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 <huzaifas at 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.

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