Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

sysctl -a | grep protected
fs.protected_hardlinks = 0
fs.protected_symlinks = 0
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlFAyvUACgkQrlYvE4MpobPhWQCfQaoeQVYAIT9CkTKA9h/u/+M8
> ZL4An0sLjnYuWnhoclsvCCxP/SBrZGws
> =WQjN
> -----END PGP SIGNATURE-----

[Seth Vidal]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 13 Mar 2013 14:52:37 -0400
Daniel J Walsh <dwalsh(a)redhat.com&gt; wrote:

>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  sysctl -a | grep protected
>  fs.protected_hardlinks = 0
>  fs.protected_symlinks = 0
>  

I apologize for the ignorance - but what do these _do_.

(please don't say they protect your hardlinks and symlinks) - I mean
what does 'protected' mean in this context.

thanks,
- -sv
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
>
> iD8DBQFRQMvB1Aj3x2mIbMcRAq1sAJ93c0UxBsYkkjD/vOA4mlDV+x854ACfdeF0
> L0XiZMhSMEV546f2616NGBM=
> =kxi7
> -----END PGP SIGNATURE-----
>

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/13/2013 02:55 PM, seth vidal wrote:
>  On Wed, 13 Mar 2013 14:52:37 -0400 Daniel J Walsh
> <dwalsh(a)redhat.com&gt;
>  wrote:
>  
> > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>  
> > sysctl -a | grep protected fs.protected_hardlinks = 0 
> > fs.protected_symlinks = 0
>  
>  
>  I apologize for the ignorance - but what do these _do_.
>  
>  (please don't say they protect your hardlinks and symlinks) - I mean what
>  does 'protected' mean in this context.
>  
>  thanks, -sv
>   
They block a non priv user from hardlinking/softlinking to files they don't own.

ln /etc/shadow ~/myshadow

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlFAzLQACgkQrlYvE4MpobNe7ACePSXtDJP5dZzgcVk6gma0HOis
> ZJEAnjRO9qcsiIeCriJOAaKku2UrQCWq
> =dp1F
> -----END PGP SIGNATURE-----

[John Reiser]

> >> sysctl -a | grep protected fs.protected_hardlinks = 0 
> >> fs.protected_symlinks = 0 
> > I apologize for the ignorance - but what do these _do_. 
>  They block a non priv user from hardlinking/softlinking to files they
> don't own.
>  
>  ln /etc/shadow ~/myshadow 
The other descriptions of fs.protected_*links say that the protection
applies to the lookup side when following a link, and not to the
creation side when installing the link.  So the potential vulnerabilities
still can be created, but damage is averted at the last possible moment.

It seems to me that the "private /tmp" feature of recent Fedora systems
has removed a large percentage of the potential vulnerabilities here.
If you cannot see anybody else's /tmp then you cannot create vulnerabilities
in /tmp for them, and they cannot create vulnerabilities in /tmp for you.

--

[Chris Adams]

Once upon a time, John Reiser <jreiser(a)bitwagon.com&gt; said:
>  The other descriptions of fs.protected_*links say that the
> protection
>  applies to the lookup side when following a link, and not to the
>  creation side when installing the link.  So the potential vulnerabilities
>  still can be created, but damage is averted at the last possible moment. 
That is for symlink protection I believe.  There's no way to do any
hardlink "protection" at lookup time.

Basically, these are two very different things being lumped together,
and they should be addressed individually.
-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Kevin Kofler]

John Reiser wrote:
>  It seems to me that the "private /tmp" feature of recent
> Fedora systems
>  has removed a large percentage of the potential vulnerabilities here.
>  If you cannot see anybody else's /tmp then you cannot create
>  vulnerabilities in /tmp for them, and they cannot create vulnerabilities
>  in /tmp for you. 
Unfortunately, private /tmp is only enabled by default in Fedora for select 
services and not for users, mainly because some programs (ab)use /tmp to do 
sockets to communicate between users.

        Kevin Kofler

[Richard W.M. Jones]

On Wed, Mar 13, 2013 at 02:55:58PM -0400, seth vidal wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  On Wed, 13 Mar 2013 14:52:37 -0400
>  Daniel J Walsh <dwalsh(a)redhat.com&gt; wrote:
>  
>  > -----BEGIN PGP SIGNED MESSAGE-----
>  > Hash: SHA1
>  > 
>  > sysctl -a | grep protected
>  > fs.protected_hardlinks = 0
>  > fs.protected_symlinks = 0
>  
>  
>  I apologize for the ignorance - but what do these _do_.
>  
>  (please don't say they protect your hardlinks and symlinks) - I mean
>  what does 'protected' mean in this context. 
See:

http://lwn.net/Articles/503660/

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

[Chris Adams]

Once upon a time, seth vidal <skvidal(a)fedoraproject.org&gt; said:
>  On Wed, 13 Mar 2013 14:52:37 -0400
>  Daniel J Walsh <dwalsh(a)redhat.com&gt; wrote:
>  > sysctl -a | grep protected
>  > fs.protected_hardlinks = 0
>  > fs.protected_symlinks = 0
>  
>  I apologize for the ignorance - but what do these _do_.
>  
>  (please don't say they protect your hardlinks and symlinks) - I mean
>  what does 'protected' mean in this context. 
I remember when these were discussed on linux-kernel, and I thought they
had some fairly small use cases (not really intended for a general
purpose system).  However, that's been a while, so off to Google...

https://lwn.net/Articles/503660/

The symlink bit stops following of symlinks in sticky, world-writable
directories, except when the UID of the symlink and process match, or
when the UID of the symlink and the directory match.  So, user 123 could
create a symlink in /tmp and follow it (but nobody else could), or root
could create a symlink in /tmp that everybody could follow.

I didn't find a detailed description of the hardlink protection right
off, however it did apparently break existing programs, so it was
disabled by default.
-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Konstantin Ryabitsev]

On Wed, Mar 13, 2013 at 2:55 PM, seth vidal <skvidal(a)fedoraproject.org&gt; wrote:
>  I apologize for the ignorance - but what do these _do_.
>
>  (please don't say they protect your hardlinks and symlinks) - I mean
>  what does 'protected' mean in this context. 
It's an fs-level implementation of Apache's SymlinksIfOwnerMatch. It
closes a number of vulnerabilities, such as taking advantages of
insecure tempfile handling (you think you're writing to
/tmp/myapp.debug, but a malicious symlink points that to
/etc/somethingoranother).

I agree that we should turn this on by default.

Best,
--
Konstantin Ryabitsev
LinuxFoundation.org
Montréal, Québec

[yersinia]

On Wed, Mar 13, 2013 at 7:52 PM, Daniel J Walsh <dwalsh(a)redhat.com&gt; wrote:

>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  sysctl -a | grep protected
>  fs.protected_hardlinks = 0
>  fs.protected_symlinks = 0
>  
Here some more info for this apparent regression
http://kernel.opensuse.org/cgit/kernel/commit/?id=561ec64ae67ef25cac8d72b...

 Best

>

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/14/2013 04:09 AM, yersinia wrote:
>  On Wed, Mar 13, 2013 at 7:52 PM, Daniel J Walsh <dwalsh(a)redhat.com
>
>  <mailto:[e-mail]>> wrote:
>  
>  -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>  
>  sysctl -a | grep protected fs.protected_hardlinks = 0 fs.protected_symlinks
>  = 0
>  
>  Here some more info for this apparent regression 
>
> http://kernel.opensuse.org/cgit/kernel/commit/?id=561ec64ae67ef25cac8d72b...
>
>   Best
>  
>  
>  
>   
Well I believe Ubunto has been using this feature for years and maybe we
should consider turning it on via systemd or a unit file.  The breakage of AFD
is not a legitimate reason for Fedora to turn it off.

Kees, could you explain how these restrictions would help secure Fedora and
any potential side effects.


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlFBy+AACgkQrlYvE4MpobO0CQCdHilzfd1TjE1RAllQ1YsmXj43
> jwIAn1KH7+Tbm+a9TBQdX5CN5vagjh8t
> =it6d
> -----END PGP SIGNATURE-----

[Casey Dahlin]

On Thu, Mar 14, 2013 at 09:08:48AM -0400, Daniel J Walsh wrote:
>  Well I believe Ubunto has been using this feature for years and maybe
> we
>  should consider turning it on via systemd or a unit file.  The breakage of AFD
>  is not a legitimate reason for Fedora to turn it off. 
Why not add an LSM call, security_follow_restricted_link()? Then you could ship
this protection with SELinux policy, and even turn it off per-label if specific
applications need the old behavior.

--CJD

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/14/2013 10:08 AM, Casey Dahlin wrote:
>  On Thu, Mar 14, 2013 at 09:08:48AM -0400, Daniel J Walsh wrote:
> > Well I believe Ubunto has been using this feature for years and maybe we 
> > should consider turning it on via systemd or a unit file.  The breakage
> > of AFD is not a legitimate reason for Fedora to turn it off.
>  
>  Why not add an LSM call, security_follow_restricted_link()? Then you could
>  ship this protection with SELinux policy, and even turn it off per-label if
>  specific applications need the old behavior.
>  
>  --CJD
>   
We already do, but this protection does protect unconfined_t and for those who
would dare to disable SELinux.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlFCFNQACgkQrlYvE4MpobN0nwCg4ynXq6hXwYzAJu1NUembARUm
> lCoAn37VntIVg7DUC2tEv9cDozKGC4IE
> =UC3e
> -----END PGP SIGNATURE-----

[Casey Dahlin]

Ok, apparently Mutt is a bit stupider than I thought. Let's try this again.

On Thu, Mar 14, 2013 at 02:20:04PM -0400, Daniel J Walsh wrote:
>  We already do, 
Good.

>  but this protection does protect unconfined_t and for those who
Maybe we're ready to except a confined user by default. Something very, very
loose.

>  would dare to disable SELinux. 
To hell with 'em. :)

--CJD

[Kees Cook]

On Thu, Mar 14, 2013 at 09:08:48AM -0400, Daniel J Walsh wrote:
>  On 03/14/2013 04:09 AM, yersinia wrote:
>  > On Wed, Mar 13, 2013 at 7:52 PM, Daniel J Walsh <dwalsh(a)redhat.com 
>  > <mailto:[e-mail]>> wrote:
>  > 
>  > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>  > 
>  > sysctl -a | grep protected fs.protected_hardlinks = 0 fs.protected_symlinks
>  > = 0
>  > 
>  > Here some more info for this apparent regression 
>  >
> http://kernel.opensuse.org/cgit/kernel/commit/?id=561ec64ae67ef25cac8d72b...
>  >
>  >  Best
>  > 
>  > 
>  > 
>  > 
>  Well I believe Ubunto has been using this feature for years and maybe we
>  should consider turning it on via systemd or a unit file.  The breakage of AFD
>  is not a legitimate reason for Fedora to turn it off.
>  
>  Kees, could you explain how these restrictions would help secure Fedora and
>  any potential side effects. 
AFD was a single specific program doing a very specific task and hardly
represents an "average workload". I remain extremely disappointed that the
default-on state was reverted. Ubuntu has had this feature enabled for
YEARS now, and it stopped quite a few exploits cold.

Everything about these restrictions is described in detail in the commit:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id...

I'm happy to answer any questions.

-Kees

-- 
Kees Cook                                            @outflux.net

[Josh Boyer]

On Thu, Mar 14, 2013 at 5:12 PM, Kees Cook <kees(a)outflux.net&gt; wrote:
>  On Thu, Mar 14, 2013 at 09:08:48AM -0400, Daniel J Walsh wrote:
> > On 03/14/2013 04:09 AM, yersinia wrote:
> > > On Wed, Mar 13, 2013 at 7:52 PM, Daniel J Walsh <dwalsh(a)redhat.com
> > > <mailto:[e-mail]>> wrote:
> > >
> > > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> > >
> > > sysctl -a | grep protected fs.protected_hardlinks = 0 fs.protected_symlinks
> > > = 0
> > >
> > > Here some more info for this apparent regression
> > >
> http://kernel.opensuse.org/cgit/kernel/commit/?id=561ec64ae67ef25cac8d72b...
> > >
> > >  Best
> > >
> > >
> > >
> > >
> > Well I believe Ubunto has been using this feature for years and maybe we
> > should consider turning it on via systemd or a unit file.  The breakage of AFD
> > is not a legitimate reason for Fedora to turn it off.
> >
> > Kees, could you explain how these restrictions would help secure Fedora and
> > any potential side effects.
>
>  AFD was a single specific program doing a very specific task and hardly
>  represents an "average workload". I remain extremely disappointed that the
>  default-on state was reverted. Ubuntu has had this feature enabled for
>  YEARS now, and it stopped quite a few exploits cold.
>
>  Everything about these restrictions is described in detail in the commit:
>
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id...
>
>  I'm happy to answer any questions. 
Something like this patch to systemd should work, no?


> From 9ee10b11d0d13554d3c59205389d6ebf665a213a Mon Sep 17 00:00:00 2001
From: Josh Boyer <jwboyer(a)redhat.com&gt;
Date: Thu, 14 Mar 2013 18:30:47 -0400
Subject: [PATCH] Turn on protected hard and soft link protection by default

---
 Makefile.am                      |  9 +++++++--
 sysctl.d/protected_links.conf.in | 11 +++++++++++
 2 files changed, 18 insertions(+), 2 deletions(-)
 create mode 100644 sysctl.d/protected_links.conf.in

diff --git a/Makefile.am b/Makefile.am
index 175d14b..68b5de9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2688,6 +2688,9 @@ pkgconfiglib_DATA += \
 dist_catalog_DATA = \
 	catalog/systemd.catalog

+sysctl_DATA = \
+	sysctl.d/protected_links.conf
+
 SOCKETS_TARGET_WANTS += \
 	systemd-journald.socket
 SYSINIT_TARGET_WANTS += \
@@ -2699,10 +2702,12 @@ EXTRA_DIST += \
 	src/journal/libsystemd-journal.sym \
 	units/systemd-journald.service.in \
 	units/systemd-journal-flush.service.in \
-	src/journal/journald-gperf.gperf
+	src/journal/journald-gperf.gperf \
+	sysctl.d/protected_links.conf.in

 CLEANFILES += \
-	src/journal/journald-gperf.c
+	src/journal/journald-gperf.c \
+	sysctl.d/protected_links.conf

 # ------------------------------------------------------------------------------
 if HAVE_MICROHTTPD
diff --git a/sysctl.d/protected_links.conf.in b/sysctl.d/protected_links.conf.in
new file mode 100644
index 0000000..f183b08
--- /dev/null
+++ b/sysctl.d/protected_links.conf.in
@@ -0,0 +1,11 @@
+#  This file is part of systemd.
+#
+#  systemd is free software; you can redistribute it and/or modify it
+#  under the terms of the GNU Lesser General Public License as published by
+#  the Free Software Foundation; either version 2.1 of the License, or
+#  (at your option) any later version.
+
+# See sysctl.d(5) for for details.
+
+fs.protected_hardlinks=1
+fs.protected_symlinks=1
-- 
1.8.1.2

[Lennart Poettering]

On Thu, 14.03.13 18:32, Josh Boyer (jwboyer(a)gmail.com) wrote:

>  > Everything about these restrictions is described in detail in
> the commit:
>  >
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id...
>  >
>  > I'm happy to answer any questions.
>  
>  Something like this patch to systemd should work, no? 
Hmm, I'd very much prefer if the defaults are built into the kernel, and
that sysctl in userspace is then used only by the admin to override these
defaults, so that by default we ship with empty sysctl.d/ dirs. 

So, before I merge anything like this into systemd, why can't the kernel
default setting simply be flipped?

>  +fs.protected_hardlinks=1
>  +fs.protected_symlinks=1 
Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Chris Adams]

Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de&gt; said:
>  Hmm, I'd very much prefer if the defaults are built into the
> kernel, and
>  that sysctl in userspace is then used only by the admin to override these
>  defaults, so that by default we ship with empty sysctl.d/ dirs. 
>  
>  So, before I merge anything like this into systemd, why can't the kernel
>  default setting simply be flipped? 
Upstream kernel said "no, distros can do it in userspace", and Fedora
aims to remain true to upstream.  Also, if upstream kernel does one
thing and Fedora kernel the opposite, users would have unexpected
defaults changing if they built their own kernel for some reason.

Why would this need to be merged into systemd?  Why not just sysctl.conf
(or I guess the new-and-improved /usr/lib/sysctl.d/00-system.conf, which
comes from initscripts)?

As is pointed out (IIRC in the commit that reverted the default), if you
can't trust the boot environment, you are already hosed.
-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Josh Boyer]

On Thu, Mar 14, 2013 at 8:28 PM, Chris Adams <cmadams(a)hiwaay.net&gt; wrote:
>  Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de&gt;
> said:
> > Hmm, I'd very much prefer if the defaults are built into the kernel, and
> > that sysctl in userspace is then used only by the admin to override these
> > defaults, so that by default we ship with empty sysctl.d/ dirs.
> >
> > So, before I merge anything like this into systemd, why can't the kernel
> > default setting simply be flipped?
>
>  Upstream kernel said "no, distros can do it in userspace", and Fedora
>  aims to remain true to upstream.  Also, if upstream kernel does one
>  thing and Fedora kernel the opposite, users would have unexpected
>  defaults changing if they built their own kernel for some reason.
>
>  Why would this need to be merged into systemd?  Why not just sysctl.conf
>  (or I guess the new-and-improved /usr/lib/sysctl.d/00-system.conf, which
>  comes from initscripts)? 
My patch put it in /usr/lib/sysctl.d, just coming from systemd itself.
We could possibly throw that file into initscripts if systemd doesn't
want to make that change (though I think Lennart would have the same
objection).

josh

[Chris Adams]

Once upon a time, Josh Boyer <jwboyer(a)gmail.com&gt; said:
>  My patch put it in /usr/lib/sysctl.d, just coming from systemd
> itself.
>  We could possibly throw that file into initscripts if systemd doesn't
>  want to make that change (though I think Lennart would have the same
>  objection). 
The rest of the standard sysctl settings are in the file
/usr/lib/sysctl.d/00-system.conf, which comes from initscripts.  I see
no reason to create another file, just to add a couple more defaults.

-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Josh Boyer]

On Thu, Mar 14, 2013 at 8:48 PM, Chris Adams <cmadams(a)hiwaay.net&gt; wrote:
>  Once upon a time, Josh Boyer <jwboyer(a)gmail.com&gt; said:
> > My patch put it in /usr/lib/sysctl.d, just coming from systemd itself.
> > We could possibly throw that file into initscripts if systemd doesn't
> > want to make that change (though I think Lennart would have the same
> > objection).
>
>  The rest of the standard sysctl settings are in the file
>  /usr/lib/sysctl.d/00-system.conf, which comes from initscripts.  I see
>  no reason to create another file, just to add a couple more defaults. 
Oh, sure.  Totally fine with me too.

josh

[Josh Boyer]

On Fri, Mar 15, 2013 at 7:42 AM, Josh Boyer <jwboyer(a)gmail.com&gt; wrote:
>  On Thu, Mar 14, 2013 at 8:48 PM, Chris Adams
> <cmadams(a)hiwaay.net&gt; wrote:
> > Once upon a time, Josh Boyer <jwboyer(a)gmail.com&gt; said:
> >> My patch put it in /usr/lib/sysctl.d, just coming from systemd itself.
> >> We could possibly throw that file into initscripts if systemd doesn't
> >> want to make that change (though I think Lennart would have the same
> >> objection).
> >
> > The rest of the standard sysctl settings are in the file
> > /usr/lib/sysctl.d/00-system.conf, which comes from initscripts.  I see
> > no reason to create another file, just to add a couple more defaults.
>
>  Oh, sure.  Totally fine with me too. 
https://bugzilla.redhat.com/show_bug.cgi?id=922030

josh

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/15/2013 09:04 AM, Josh Boyer wrote:
>  On Fri, Mar 15, 2013 at 7:42 AM, Josh Boyer <jwboyer(a)gmail.com&gt;
> wrote:
> > On Thu, Mar 14, 2013 at 8:48 PM, Chris Adams <cmadams(a)hiwaay.net&gt; wrote:
> >> Once upon a time, Josh Boyer <jwboyer(a)gmail.com&gt; said:
> >>> My patch put it in /usr/lib/sysctl.d, just coming from systemd
> >>> itself. We could possibly throw that file into initscripts if systemd
> >>> doesn't want to make that change (though I think Lennart would have
> >>> the same objection).
> >> 
> >> The rest of the standard sysctl settings are in the file 
> >> /usr/lib/sysctl.d/00-system.conf, which comes from initscripts.  I see 
> >> no reason to create another file, just to add a couple more defaults.
> > 
> > Oh, sure.  Totally fine with me too.
>  
>  https://bugzilla.redhat.com/show_bug.cgi?id=922030
>  
>  josh
>   
I guess we could open a feature page for this for F20, or do we want to pull
it into F19.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlFDKOMACgkQrlYvE4MpobOUAQCgwWTKB5d+sB7n+n+vf9mYJ90I
> Do4AmgOxvV4R3UR3qAemRaU9uGIEN24H
> =wFhV
> -----END PGP SIGNATURE-----

[Josh Boyer]

On Fri, Mar 15, 2013 at 9:57 AM, Daniel J Walsh <dwalsh(a)redhat.com&gt; wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  On 03/15/2013 09:04 AM, Josh Boyer wrote:
> > On Fri, Mar 15, 2013 at 7:42 AM, Josh Boyer <jwboyer(a)gmail.com&gt; wrote:
> >> On Thu, Mar 14, 2013 at 8:48 PM, Chris Adams <cmadams(a)hiwaay.net&gt; wrote:
> >>> Once upon a time, Josh Boyer <jwboyer(a)gmail.com&gt; said:
> >>>> My patch put it in /usr/lib/sysctl.d, just coming from systemd
> >>>> itself. We could possibly throw that file into initscripts if systemd
> >>>> doesn't want to make that change (though I think Lennart would have
> >>>> the same objection).
> >>>
> >>> The rest of the standard sysctl settings are in the file
> >>> /usr/lib/sysctl.d/00-system.conf, which comes from initscripts.  I see
> >>> no reason to create another file, just to add a couple more defaults.
> >>
> >> Oh, sure.  Totally fine with me too.
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=922030
> >
> > josh
> >
>  I guess we could open a feature page for this for F20, or do we want to pull
>  it into F19. 
I don't think this needs a feature page.  I'd like to see it in F19.
There's a case to be made for enabling it on the other releases too, but
F19 is a good target to start with.

josh

[Chris Adams]

Once upon a time, Josh Boyer <jwboyer(a)gmail.com&gt; said:
>  I don't think this needs a feature page.  I'd like to see it
> in F19.
>  There's a case to be made for enabling it on the other releases too, but
>  F19 is a good target to start with. 
I agree that it doesn't really need a feature page, but IMHO it should
be in the release notes (this is something that could break existing
programs).  It _shouldn't_ be an issue, but I don't think it is a good
idea to enable this on released versions.

If it is going to be changed for F19, the change should land ASAP so any
potential issues can be found during testing.
-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Rahul Sundaram]

On 03/15/2013 10:52 AM, Chris Adams wrote:
>  I agree that it doesn't really need a feature page, but IMHO it
> should
>  be in the release notes (this is something that could break existing
>  programs). 
  Here you go

https://fedoraproject.org/wiki/Documentation_Security_Beat

Rahul

[Pete Travis]

On Mar 15, 2013 10:13 AM, "Rahul Sundaram" <metherid(a)gmail.com&gt; wrote:
>  On 03/15/2013 10:52 AM, Chris Adams wrote:
> >
> > I agree that it doesn't really need a feature page, but IMHO it should
> > be in the release notes (this is something that could break existing
> > programs).
>
>   Here you go
>
>  https://fedoraproject.org/wiki/Documentation_Security_Beat
>
>  Rahul
>
>  -- 
That is an excellent explanation, thanks Rahul!

--Pete

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/15/2013 11:11 AM, Rahul Sundaram wrote:
>  On 03/15/2013 10:52 AM, Chris Adams wrote:
> > I agree that it doesn't really need a feature page, but IMHO it should be
> > in the release notes (this is something that could break existing 
> > programs).
>  Here you go
>  
>  https://fedoraproject.org/wiki/Documentation_Security_Beat
>  
>  Rahul 
I a not sure private tmp for allowed would solve this problem,  since you
could still attempt to trick a setuid app to read a link.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlFJs/QACgkQrlYvE4MpobNh9QCfaxkpmf4oFnTVlpgJ1IDzMM+S
> mu4AnitJ5/d9NCm/RfBtYcAiRioaU3fU
> =TiHs
> -----END PGP SIGNATURE-----

[Josh Boyer]

On Thu, Mar 14, 2013 at 8:22 PM, Lennart Poettering
<mzerqung(a)0pointer.de&gt; wrote:
>  On Thu, 14.03.13 18:32, Josh Boyer (jwboyer(a)gmail.com) wrote:
>
> > > Everything about these restrictions is described in detail in the commit:
> > >
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id...
> > >
> > > I'm happy to answer any questions.
> >
> > Something like this patch to systemd should work, no?
>
>  Hmm, I'd very much prefer if the defaults are built into the kernel, and
>  that sysctl in userspace is then used only by the admin to override these
>  defaults, so that by default we ship with empty sysctl.d/ dirs.
>
>  So, before I merge anything like this into systemd, why can't the kernel
>  default setting simply be flipped? 
It would be yet another out-of-tree patch to carry along forever in
Fedora.  Or at best we try and upstream the default as a config setting
but I'm not sure Linus would bite on that given his commit message when
he switched the default to disabled.  I'd rather avoid carrying a patch
that has no chance of upstream when it can be done by a unit file or
systemd itself.  That's why they're settable from userspace to begin
with.

josh

[Josh Boyer]

On Thu, Mar 14, 2013 at 8:28 PM, Josh Boyer <jwboyer(a)gmail.com&gt; wrote:
>  On Thu, Mar 14, 2013 at 8:22 PM, Lennart Poettering
>  <mzerqung(a)0pointer.de&gt; wrote:
> > On Thu, 14.03.13 18:32, Josh Boyer (jwboyer(a)gmail.com) wrote:
> >
> >> > Everything about these restrictions is described in detail in the commit:
> >> >
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id...
> >> >
> >> > I'm happy to answer any questions.
> >>
> >> Something like this patch to systemd should work, no?
> >
> > Hmm, I'd very much prefer if the defaults are built into the kernel, and
> > that sysctl in userspace is then used only by the admin to override these
> > defaults, so that by default we ship with empty sysctl.d/ dirs.
> >
> > So, before I merge anything like this into systemd, why can't the kernel
> > default setting simply be flipped?
>
>  It would be yet another out-of-tree patch to carry along forever in
>  Fedora.  Or at best we try and upstream the default as a config setting
>  but I'm not sure Linus would bite on that given his commit message when
>  he switched the default to disabled.  I'd rather avoid carrying a patch
>  that has no chance of upstream when it can be done by a unit file or
>  systemd itself.  That's why they're settable from userspace to begin
>  with. 
Oh, right.  Kees already tried the config option route:

http://thread.gmane.org/gmane.linux.kernel/1383391/focus=1383496

Failed.

So, back to "carry a patch in the kernel forever", which I'd really like
to avoid.

josh

[Kevin Kofler]

Kees Cook wrote:
>  AFD was a single specific program doing a very specific task and
> hardly
>  represents an "average workload". I remain extremely disappointed that the
>  default-on state was reverted. Ubuntu has had this feature enabled for
>  YEARS now, and it stopped quite a few exploits cold. 
Who knows what other applications this extremely surprising and incompatible 
change breaks? (IMHO, even private /tmp is a better solution. It's also an 
incompatible change, but at least it has semantics a normal user can 
understand, whereas your solution layers really complicated hidden rules on 
top of something as basic as file permissions.)

I'm with Linus when he says "Breaking applications is unacceptable. End of 
story. It's broken them. Get over it." We aren't ready to enable private 
/tmp for the same reason, so why is this hack any more acceptable?

IMHO the initscripts change should be reverted and we should stick to 
Linus's defaults. He said "no" for a reason.

        Kevin Kofler

[Miloslav Trmač]

On Sun, Mar 17, 2013 at 10:07 PM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  Kees Cook wrote:
> > AFD was a single specific program doing a very specific task and hardly
> > represents an "average workload". I remain extremely disappointed that the
> > default-on state was reverted. Ubuntu has had this feature enabled for
> > YEARS now, and it stopped quite a few exploits cold.
>
>  Who knows what other applications this extremely surprising and incompatible
>  change breaks? 
BTW determining this accurately should be fairly doable[1].  Just look
for symlink() and link() calls (and recursively through wrapper APIs /
language bindings).  These syscalls are fairly rare.
    Mirek

[1] Well, "fairly doable" when compared to the /tmp-on-tmpfs, which is
"just impossible".  It's still man-weeks of work.  Pragmatically
speaking, "It did not break Ubuntu" is not a QA technique that makes
me happy, but might be good enough anyway.

[Kevin Kofler]

Miloslav Trmač wrote:
>  BTW determining this accurately should be fairly doable[1].  Just
> look
>  for symlink() and link() calls (and recursively through wrapper APIs /
>  language bindings).  These syscalls are fairly rare. 
That checks for PROGRAMS which run into this. It catches neither admin's 
custom scripts nor ln commands run directly by the users. Who knows on how 
many machines manually created symlinks point to inodes owned by different 
users?

>  [1] Well, "fairly doable" when compared to the
> /tmp-on-tmpfs, which is
>  "just impossible".  It's still man-weeks of work.  Pragmatically
>  speaking, "It did not break Ubuntu" is not a QA technique that makes
>  me happy, but might be good enough anyway. 
Well, /tmp-on-tmpfs is just broken, disabled on my machines and should be 
reverted in Fedora ASAP. It is not a good example to follow (and neither is 
UsrMove, whose consequences we're still suffering, see the recent thread 
about RPM dependencies on binaries).

        Kevin Kofler

[Nico Kadel-Garcia]

On Sat, Mar 23, 2013 at 11:08 PM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  Miloslav Trmač wrote:
> > BTW determining this accurately should be fairly doable[1].  Just look
> > for symlink() and link() calls (and recursively through wrapper APIs /
> > language bindings).  These syscalls are fairly rare.
>
>  That checks for PROGRAMS which run into this. It catches neither admin's
>  custom scripts nor ln commands run directly by the users. Who knows on how
>  many machines manually created symlinks point to inodes owned by different
>  users? 
For example, I've been known to link /sbin programs to $HOME/bin/. on
hosts I use and do not have root access on, so that "traceroute" iour
"chkconfig" or the "hardlink" program are always avaialble. The
decision to leave "/sbin" out of the default PATH except for root
users has created many interesting such situations. This is especially
true in environments where commercial or experimental versions of gcc
or Java are instlled in /usr/local/gcc or /usr/local/java or
/opt/[package] on some hosts and not others, and need to be activated
on a user-by-user basis.

> > [1] Well, "fairly doable" when compared to the
> /tmp-on-tmpfs, which is
> > "just impossible".  It's still man-weeks of work.  Pragmatically
> > speaking, "It did not break Ubuntu" is not a QA technique that makes
> > me happy, but might be good enough anyway.
>
>  Well, /tmp-on-tmpfs is just broken, disabled on my machines and should be
>  reverted in Fedora ASAP. It is not a good example to follow (and neither is
>  UsrMove, whose consequences we're still suffering, see the recent thread
>  about RPM dependencies on binaries). 
Amen.

[Michael Scherer]

Le dimanche 24 mars 2013 à 09:05 -0400, Nico Kadel-Garcia a écrit :
>  On Sat, Mar 23, 2013 at 11:08 PM, Kevin Kofler
> <kevin.kofler(a)chello.at&gt; wrote:
>  > Miloslav Trmač wrote:
>  >> BTW determining this accurately should be fairly doable[1].  Just look
>  >> for symlink() and link() calls (and recursively through wrapper APIs /
>  >> language bindings).  These syscalls are fairly rare.
>  >
>  > That checks for PROGRAMS which run into this. It catches neither admin's
>  > custom scripts nor ln commands run directly by the users. Who knows on how
>  > many machines manually created symlinks point to inodes owned by different
>  > users?
>  
>  For example, I've been known to link /sbin programs to $HOME/bin/. on
>  hosts I use and do not have root access on, so that "traceroute" iour
>  "chkconfig" or the "hardlink" program are always avaialble. The
>  decision to leave "/sbin" out of the default PATH except for root
>  users has created many interesting such situations.  
You can also just fix the path for your user.

>  This is especially
>  true in environments where commercial or experimental versions of gcc
>  or Java are instlled in /usr/local/gcc or /usr/local/java or
>  /opt/[package] on some hosts and not others, and need to be activated
>  on a user-by-user basis. 
Unless your $HOME/bin is using a sticky bit and is world writable
like /tmp, this will change nothing for you.

See
http://users.sosdg.org/~qiyong/lxr/source/Documentation/sysctl/fs.txt#L160 for more
information.

Also, for the record, Debian also enable it for the next stable
release :
http://womble.decadent.org.uk/blog/whats-in-the-linux-kernel-for-debian-7...
( along other interesting things, like disable autoloading for seldomly
used network protocols )

-- 
Michael Scherer

[Reindl Harald]

Am 24.03.2013 04:08, schrieb Kevin Kofler:
>  Miloslav Trmač wrote:
> > BTW determining this accurately should be fairly doable[1].  Just look
> > for symlink() and link() calls (and recursively through wrapper APIs /
> > language bindings).  These syscalls are fairly rare.
>  
>  That checks for PROGRAMS which run into this. It catches neither admin's 
>  custom scripts nor ln commands run directly by the users. Who knows on how 
>  many machines manually created symlinks point to inodes owned by different 
>  users? 
maybe you guys should read what the protection does
how many directories except /tmp are world-writeable and have STICKY bit?

fs.protected_symlink
symlinks to only be followed when outside a sticky world-writable directory

fs.protected_hardlinks
blocks hardlinks to other people's WORLD-READABLE files if you can't write to
them

[Nico Kadel-Garcia]

Reading from the spec:

>  The solution is to permit symlinks to only be followed when outside a
> sticky world-writable directory, or when the uid of the symlink and follower match, or
> when the directory owner matches the symlink's owner. 
It was a bit unclear to me the first time I read it: I thought it was
"and", not "or". So this is not as restrictive as I thought, and
I'll
withdraw my conerrn about this breaking linking /sbin/* or /us/sbin/*
programs to $HOME//bin/.

On Sun, Mar 24, 2013 at 9:19 AM, Reindl Harald <h.reindl(a)thelounge.net&gt; wrote:
>  Am 24.03.2013 04:08, schrieb Kevin Kofler:
> > Miloslav Trmač wrote:
> >> BTW determining this accurately should be fairly doable[1].  Just look
> >> for symlink() and link() calls (and recursively through wrapper APIs /
> >> language bindings).  These syscalls are fairly rare.
> >
> > That checks for PROGRAMS which run into this. It catches neither admin's
> > custom scripts nor ln commands run directly by the users. Who knows on how
> > many machines manually created symlinks point to inodes owned by different
> > users?
>
>  maybe you guys should read what the protection does
>  how many directories except /tmp are world-writeable and have STICKY bit?
>
>  fs.protected_symlink
>  symlinks to only be followed when outside a sticky world-writable directory
>
>  fs.protected_hardlinks
>  blocks hardlinks to other people's WORLD-READABLE files if you can't write to
> them
>
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[Kees Cook]

On Sun, Mar 17, 2013 at 10:07:48PM +0100, Kevin Kofler wrote:
>  Kees Cook wrote:
>  > AFD was a single specific program doing a very specific task and hardly
>  > represents an "average workload". I remain extremely disappointed that
> the
>  > default-on state was reverted. Ubuntu has had this feature enabled for
>  > YEARS now, and it stopped quite a few exploits cold.
>  
>  Who knows what other applications this extremely surprising and incompatible 
>  change breaks? (IMHO, even private /tmp is a better solution. It's also an 
>  incompatible change, but at least it has semantics a normal user can 
>  understand, whereas your solution layers really complicated hidden rules on 
>  top of something as basic as file permissions.)
>  
>  I'm with Linus when he says "Breaking applications is unacceptable. End of 
>  story. It's broken them. Get over it." We aren't ready to enable private 
>  /tmp for the same reason, so why is this hack any more acceptable?
>  
>  IMHO the initscripts change should be reverted and we should stick to 
>  Linus's defaults. He said "no" for a reason. 
https://lwn.net/Articles/543273/
"On a vanilla kernel, protected_hardlinks unfortunately has the default
value zero" That's what Linus's defaults get: vulnerable-by-default.

Specialized applications are the exception, and if you use them, it's your
responsibility to tune your system as needed. Why leave your system
vulnerable to script-kiddie attacks by default?

The semantics of both world-writable sticky directories and hardlink
access are undefined by POSIX. This fix was not a "hack", it corrects a
bad decision made over a decade ago that was overwhelming more commonly
used for vulnerability exploitation purposes.

-Kees

-- 
Kees Cook                                            @outflux.net

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/20/2013 09:49 PM, Kees Cook wrote:
>  On Sun, Mar 17, 2013 at 10:07:48PM +0100, Kevin Kofler wrote:
> > Kees Cook wrote:
> >> AFD was a single specific program doing a very specific task and
> >> hardly represents an "average workload". I remain extremely
> >> disappointed that the default-on state was reverted. Ubuntu has had
> >> this feature enabled for YEARS now, and it stopped quite a few exploits
> >> cold.
> > 
> > Who knows what other applications this extremely surprising and
> > incompatible change breaks? (IMHO, even private /tmp is a better
> > solution. It's also an incompatible change, but at least it has semantics
> > a normal user can understand, whereas your solution layers really
> > complicated hidden rules on top of something as basic as file
> > permissions.)
> > 
> > I'm with Linus when he says "Breaking applications is unacceptable. End
> > of story. It's broken them. Get over it." We aren't ready to enable
> > private /tmp for the same reason, so why is this hack any more
> > acceptable?
> > 
> > IMHO the initscripts change should be reverted and we should stick to 
> > Linus's defaults. He said "no" for a reason.
>  
>  https://lwn.net/Articles/543273/ "On a vanilla kernel, protected_hardlinks
>  unfortunately has the default value zero" That's what Linus's defaults get:
>  vulnerable-by-default.
>  
>  Specialized applications are the exception, and if you use them, it's your 
>  responsibility to tune your system as needed. Why leave your system 
>  vulnerable to script-kiddie attacks by default?
>  
>  The semantics of both world-writable sticky directories and hardlink access
>  are undefined by POSIX. This fix was not a "hack", it corrects a bad
>  decision made over a decade ago that was overwhelming more commonly used
>  for vulnerability exploitation purposes.
>  
>  -Kees
>   
I agree, we make lots of decisions in the OS that have the ability to break
applications by default.  FireWall, SELinux, Services disabled by default, not
allowing tons of setuid apps, other settings like mmap_zero.

If we do not secure the machine by default then no users, especially naive
users will turn on these protections.

Linus has different requirements for the kernel, but leaves it up to the
distributions to configure the kernel.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlFLCGQACgkQrlYvE4MpobOuqQCgyX7uHmRCo8HzSEiVLrKXggbL
> UX4An3hrqSLprTbv2zcEYmZ0dUh3SphI
> =1WRB
> -----END PGP SIGNATURE-----