Re: F22 System Wide Change: Enable Polyinstantiated /tmp and /var/tmp directories by default
On Wed, Jan 21, 2015 at 4:59 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Wed, 21.01.15 09:49, Daniel J Walsh (dwa...@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. https://lists.fedoraproject.org/pipermail/devel/2011-January/147611.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Enable Polyinstantiated /tmp and /var/tmp directories by default
On Wed, 21.01.15 09:49, Daniel J Walsh (dwa...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Enable Polyinstantiated /tmp and /var/tmp directories by default
On 01/20/2015 05:59 PM, Lennart Poettering wrote: 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. Did you read the attached references to the proposal? X11 is a special case of needed a shared temp. directory between root and a no-root process. The reference has a way to solve this problem. afaik, non-root xorg wont need this hack anymore. 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? /tmp-inst is created with mode 000, as compared to /tmp. As per the documentation pam_namespace will enforce this mode, unless explicitly asked to bypass this. 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. Private tmp instances are NOT removed. Only access to them is restricted to process which run as the $user. To me this sounds very much not thought to the end. Maybe you should try doing this once and see how it scales? 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 -- Huzaifa Sidhpurwala / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Enable Polyinstantiated /tmp and /var/tmp directories by default
On Wed, 21.01.15 14:34, Huzaifa Sidhpurwala (huzai...@redhat.com) wrote: On 01/20/2015 05:59 PM, Lennart Poettering wrote: 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. Did you read the attached references to the proposal? I read your feature page. How about adding comments about these things to the proposal itself? X11 is a special case of needed a shared temp. directory between root and a no-root process. The reference has a way to solve this problem. So, are you proposing to run a shell script on each login, that bind mounts the 5 X11 dirs back into each user's tmp directory? That's a hack, little else... afaik, non-root xorg wont need this hack anymore. Well, the path to the AF_UNIX sockets is compiled into many 3rd party. If you change it, you break things... 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. I'd really like to hear your response to this issue. This is a killer really. 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? /tmp-inst is created with mode 000, as compared to /tmp. As per the documentation pam_namespace will enforce this mode, unless explicitly asked to bypass this. Hmm? I don't follow here... Why is this in anyway better than giving each user his own directory directly below /tmp (with a non-guessable name), that is owned and accessible only to him? 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. Private tmp instances are NOT removed. Only access to them is restricted to process which run as the $user. Well, we have automatic cleanup for /tmp in place for a reason. What's your plan there for /tmp-inst? To me this sounds very much not thought to the end. Maybe you should try doing this once and see how it scales? I have no doubts about scalability. Also, I implemented all the private /tmp stuff in systemd, for PrivateTmp=. I think I did my homework to be allowed to comment on this. Thanks! I just think that this is not useful in real life on general purpose distros. You can do this on specific machines where you know that it's OK to break mounts from users sessions, and where you know you never will use X11 software. But that's a special case, and inappropriate for a general purpose distro like Fedora. I am also quite sure that the pam_namespace solution which runs privileged shell scripts in the background and duplicates all temp dirs, is hacky, and nothing we should make the default. This feature is really a *bad* idea. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Enable Polyinstantiated /tmp and /var/tmp directories by default
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
Re: F22 System Wide Change: Enable Polyinstantiated /tmp and /var/tmp directories by default
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. 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Enable Polyinstantiated /tmp and /var/tmp directories by default
On 20/01/15 12:16, Tomas Hozza wrote: On 01/20/2015 01:08 PM, Tom Hughes wrote: On 20/01/15 11:53, Jaroslav Reznik 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) So this effectively reverses tmp-on-tmpfs for users other than root and adm right? Because /tmp will actually be a subdirectory of /tmp-inst which will be a real directory? Why do you think this? I don't see any reason why the new tmp-inst directories can not be on tmpfs... I guess that will work as well, but it wasn't clear that was the intention since it talked of adding them to the filesystem package. I suppose technically the directories still exist in filesystem but currently it is systemd that then overmounts them with tmpfs instances. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Enable Polyinstantiated /tmp and /var/tmp directories by default
On 01/20/2015 01:08 PM, Tom Hughes wrote: On 20/01/15 11:53, Jaroslav Reznik 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) So this effectively reverses tmp-on-tmpfs for users other than root and adm right? Because /tmp will actually be a subdirectory of /tmp-inst which will be a real directory? Why do you think this? I don't see any reason why the new tmp-inst directories can not be on tmpfs... Incidentally, why /tmp-inst but /var/tmp/tmp-inst? Why not /tmp/tmp-inst for /tmp or /var/tmp-inst for /var/tmp? Shouldn't the naming be consistent? Tom Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Enable Polyinstantiated /tmp and /var/tmp directories by default
On 20/01/15 11:53, Jaroslav Reznik 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) So this effectively reverses tmp-on-tmpfs for users other than root and adm right? Because /tmp will actually be a subdirectory of /tmp-inst which will be a real directory? Incidentally, why /tmp-inst but /var/tmp/tmp-inst? Why not /tmp/tmp-inst for /tmp or /var/tmp-inst for /var/tmp? Shouldn't the naming be consistent? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Enable Polyinstantiated /tmp and /var/tmp directories by default
On 01/20/2015 11:53 AM, Jaroslav Reznik 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) * Release engineering: N/A * Policies and guidelines: N/A == Contingency Plan == * Contingency mechanism: Poly tmp can be rolled back quite easily, by using the previous versions of packages which provides the old directory structures and old versions of the configuration files (poly tmp is just configuration and a few new directories). In releases earlier gnome-shell had issues with poly tmp, which now seems to be resolved. In any case, by Beta deadline if any blockers exists, we can easily remove this feature, by tagging previous versions of the affected packages, before the final spin. * Contingency deadline: Beta freeze * Blocks release? No [1] http://red.ht/1EkZ1gT __ Assuming this wont collide with existing setup systemd provides, what benefits does this provide over systemds /tmp /var/tmp setup and PrivateTmp? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
