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

2015-01-21 Thread drago01
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

2015-01-21 Thread Lennart Poettering
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

2015-01-21 Thread Huzaifa Sidhpurwala
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

2015-01-21 Thread Lennart Poettering
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

2015-01-21 Thread Daniel J Walsh

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

2015-01-20 Thread Lennart Poettering
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

2015-01-20 Thread Tom Hughes

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

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

2015-01-20 Thread Jaroslav Reznik
= 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
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

2015-01-20 Thread Jaroslav Reznik
= 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
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

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

2015-01-20 Thread Tomas Hozza
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

2015-01-20 Thread Tom Hughes

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

2015-01-20 Thread J├│hann B. Gu├░mundsson


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