Re: [gentoo-dev] Re: Improve the security of the default profile

[Richard Yao]

On 09/12/2013 11:03 AM, Richard Yao wrote:
 On 09/10/2013 09:17 PM, Rich Freeman wrote:
 On Tue, Sep 10, 2013 at 6:41 PM, Richard Yao r...@gentoo.org wrote:
 1. The kernel expects -fno-stack-protector to be the default. What will
 the effect be on kernel configuration once -fstack-protector is the default?

 Nothing, since the kernel build system doesn't source make.conf.  If
 somebody creates an ebuild that actually installs a kernel then it
 might be an issue, though it could be filtered if it is a problem.
 
 My understanding is that this change would be made to GCC's spec files,
 which affects everything that uses GCC.
 

 2. We should make sure that -fno-stack-protector is a supported CFLAG.
 This will make it easier to handle complaints from the vocal minority of
 our user base that want every last percentage point of performance.

 No reason that it would be any less supported than -fstack-protector
 already is.
 
 Just making certain.
 

 3. I would like to point out that we are talking about deviating from
 upstream behavior and everyone is okay with it. Anyone who thinks we
 should stick to upstream when it is not good for us should speak now or
 risk being asked where were you when... whenever they try to use
 upstream as an excuse to hold back progress. ;)

 I don't really see this as an issue - in general maintainers are
 expected to accommodate reasonable CFLAGS.  This doesn't mean that
 arbitrary CFLAGS are supported so much as bugs should be taken
 seriously if they're really bugs.  If -fstack-protector causes serious
 problems and this is inherent to the nature of the package/etc then
 just filter it.  If it causes problems because upstream isn't doing
 things right, then this is no different than how things were 10 years
 ago when we were stomping out amd64 issues left and right (not working
 on amd64 wasn't a reason to mask a package for x86, but we didn't
 accept upstream doesn't care about amd64 as an excuse).

 Staying close to upstream is a good philosophy in general.  I don't
 think that means that we can't have reasonable CFLAGS.  Otherwise we
 wouldn't set CFLAGS at all and would just use whatever defaults the
 upstream build system applies.  We're a distro - doing integration
 work is a value-add, not a sin.  If we aren't doing integration, then
 users might as well just do Linux-from-scratch.

 Rich

 
 Past events have led me to think that we are sometimes too dependent on
 upstream for guidance.  I have certainly deviated from upstream whenever
 it made sense and the results have been fairly positive. I am not saying
 that acting for the best interests of Gentoo is mutually exclusive with
 collaboration with upstream, but I am saying that the two sometimes
 conflict. This being one of them. I am taking this opportunity to point
 out that what is best for Gentoo should come first and that it is okay
 to make decisions on our own.
 

I just checked the kernel's makefiles. It does pass -fno-stack-protector
when the option is disabled. Therefore a GCC spec file change will not
have cause GCC to generate kernels that differ from their .config files.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Improve the security of the default profile

[Anthony G. Basile]

On 09/07/2013 05:11 PM, Ryan Hill wrote:

On Sat, 7 Sep 2013 18:10:42 + (UTC)
Martin Vaeth va...@mathematik.uni-wuerzburg.de wrote:


Ryan Hill dirtye...@gentoo.org wrote:

* -fstack-protector{-all}
No thank you.  -fstack-protector has very limited coverage

I'd say it covers most cases where bugs can be made,
practically without a severe impact on execution time or code size.

The numbers I've seen show a maximum of 5% coverage for code that has a large
number of functions containing char arrays on the stack.  Most code doesn't fall
into that category.  Coverage of perl was 0.5%, xorg 5%, kernel 3%.  Those are
really old numbers though.  The most recent I've seen is Chromium's coverage is
2%.  There is an upper bound of 8% performance overhead using -fstack-protector
according to the design spec.  If you guys are okay with that then we can try
enabling it for 4.8.1.


* -Wl,-z,relro
Enabled by default since binutils 2.18

This gives its real impact on secutiry only when combined with

* -Wl,-z,now

The latter is not enabled by default AFAIK.

That's a bit misleading.  Immediate binding does allow the GOT to be made
readonly but relro does a lot more than that.  In any case this is a firm no.
The increase in loading times for apps that link lots of libraries is
significant (if it wasn't, we wouldn't need lazy loading :p).  If you want full
relro, enable it yourself or use hardened.


I would like to suggest also another flag

* -Wl,-z,noexecstack

This should be the default, but e.g. some broken gcc versions
forgot this default when using -flto.
I am using this flag since I realized this -flto bug and never
had any problems with it.

Well, portage will already tell you if your package installed any binaries with
executable stacks and I don't see many of those warnings that aren't binary
packages so I think we're good.


* -Wl,--hash-style={both,gnu}

I don't know what this has to do with security.

I'm just responding to the list on the Ubuntu page.


However, isn't it time to use gnu now for all users?  Except for
very strange binary-only code it should not cause any problems.
The majority of users would not realize a difference but profit
from smaller binaries.

Sure, but the sysv hash is teeny and backward compatibility is always nice if
it's next to free.

Here are some more resources if anyone is interested:

https://wiki.debian.org/Hardening
https://bugs.archlinux.org/task/18864
https://wiki.gentoo.org/wiki/Project:Hardened/GNU_stack_quickstart
http://tk-blog.blogspot.ca/2009/02/relro-not-so-well-known-memory.html



The hardened team has talked about this in IRC and our general feeling 
is that adding *just* ssp to vanilla gcc specs is okay. While there are 
some performance hits, it is generally safe and should cause little 
problems to our users.  The other hardened features, however, have more 
of an impact and probably don't belong in vanilla as already discussed.


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Re: Improve the security of the default profile

[Richard Yao]

On 09/10/2013 09:17 PM, Rich Freeman wrote:
 On Tue, Sep 10, 2013 at 6:41 PM, Richard Yao r...@gentoo.org wrote:
 1. The kernel expects -fno-stack-protector to be the default. What will
 the effect be on kernel configuration once -fstack-protector is the default?
 
 Nothing, since the kernel build system doesn't source make.conf.  If
 somebody creates an ebuild that actually installs a kernel then it
 might be an issue, though it could be filtered if it is a problem.

My understanding is that this change would be made to GCC's spec files,
which affects everything that uses GCC.


 2. We should make sure that -fno-stack-protector is a supported CFLAG.
 This will make it easier to handle complaints from the vocal minority of
 our user base that want every last percentage point of performance.
 
 No reason that it would be any less supported than -fstack-protector
 already is.

Just making certain.


 3. I would like to point out that we are talking about deviating from
 upstream behavior and everyone is okay with it. Anyone who thinks we
 should stick to upstream when it is not good for us should speak now or
 risk being asked where were you when... whenever they try to use
 upstream as an excuse to hold back progress. ;)
 
 I don't really see this as an issue - in general maintainers are
 expected to accommodate reasonable CFLAGS.  This doesn't mean that
 arbitrary CFLAGS are supported so much as bugs should be taken
 seriously if they're really bugs.  If -fstack-protector causes serious
 problems and this is inherent to the nature of the package/etc then
 just filter it.  If it causes problems because upstream isn't doing
 things right, then this is no different than how things were 10 years
 ago when we were stomping out amd64 issues left and right (not working
 on amd64 wasn't a reason to mask a package for x86, but we didn't
 accept upstream doesn't care about amd64 as an excuse).
 
 Staying close to upstream is a good philosophy in general.  I don't
 think that means that we can't have reasonable CFLAGS.  Otherwise we
 wouldn't set CFLAGS at all and would just use whatever defaults the
 upstream build system applies.  We're a distro - doing integration
 work is a value-add, not a sin.  If we aren't doing integration, then
 users might as well just do Linux-from-scratch.
 
 Rich
 

Past events have led me to think that we are sometimes too dependent on
upstream for guidance.  I have certainly deviated from upstream whenever
it made sense and the results have been fairly positive. I am not saying
that acting for the best interests of Gentoo is mutually exclusive with
collaboration with upstream, but I am saying that the two sometimes
conflict. This being one of them. I am taking this opportunity to point
out that what is best for Gentoo should come first and that it is okay
to make decisions on our own.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Improve the security of the default profile

[Richard Yao]

On 09/11/2013 02:07 AM, Ryan Hill wrote:
 On Tue, 10 Sep 2013 18:41:34 -0400
 Richard Yao r...@gentoo.org wrote:
 
 A few thoughts:

 1. The kernel expects -fno-stack-protector to be the default. What will
 the effect be on kernel configuration once -fstack-protector is the default?
 
 The kernel has supported building with -fstack-protector since 2.6.19, (at 
 least
 on x86/x86-64).  It's controlled by CONFIG_CC_STACKPROTECTOR and if it's
 disabled then -fno-stack-protector is explicitly added to the command line.

That is good news. I admit that I was being lazy in not looking this up
myself, but things probably are more efficient when the people already
looking into this are the ones who check these loose ends.

 2. We should make sure that -fno-stack-protector is a supported CFLAG.
 This will make it easier to handle complaints from the vocal minority of
 our user base that want every last percentage point of performance.
 
 If by supported you mean that they won't be removed by things like 
 strip-flags,
 then yes, -fstack-protector -fstack-protector-all -fno-stack-protector and
 -fno-stack-protector-all are all on the whitelist.

That is good.

 3. I would like to point out that we are talking about deviating from
 upstream behavior and everyone is okay with it. Anyone who thinks we
 should stick to upstream when it is not good for us should speak now or
 risk being asked where were you when... whenever they try to use
 upstream as an excuse to hold back progress. ;)
 
 In this case it seems every other distro is already doing this, so we're in
 good company.

Agreed. I just wanted to say something as insurance for the future. ;)

Anyway, I will be happy to see it integrated into the tree once all of
the hacks around it have been corrected.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: Improve the security of the default profile

[Ryan Hill]

On Thu, 12 Sep 2013 11:23:04 -0400
Anthony G. Basile bluen...@gentoo.org wrote:

 The hardened team has talked about this in IRC and our general feeling 
 is that adding *just* ssp to vanilla gcc specs is okay. While there are 
 some performance hits, it is generally safe and should cause little 
 problems to our users.  The other hardened features, however, have more 
 of an impact and probably don't belong in vanilla as already discussed.

https://bugs.gentoo.org/484714


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

[gentoo-dev] Re: Improve the security of the default profile

[Ryan Hill]

On Wed, 11 Sep 2013 04:49:55 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:

 If I'm not mistaken, dirtyepic intends to patch gcc directly to enable 
 -fstack-protector, changing the default at that level so it'll be used 
 unless -fno-stack-protector is in CFLAGS.  At least, that's how I 
 interpret (dirtyepic):
 
   'filter-flags -fstack-protector [won't] actually work
   (we have to patch the compiler, not just add it to the
   default flags in the profiles or something).

Actually it turns out I was completely wrong about this.  The hardened flag
filtering in flag-o-matic dumps the compiler specs (the rules that
determine what flags to use) to check if hardened features are enabled
and only negates them if they are.  The quick hack I did for my testing was
failing that check so the flags weren't being disabled.


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Improve the security of the default profile

[Magnus Granberg]

onsdag 11 september 2013 00.07.29 skrev  Ryan Hill:
 On Tue, 10 Sep 2013 18:41:34 -0400
 
 Richard Yao r...@gentoo.org wrote:
  A few thoughts:
  
  1. The kernel expects -fno-stack-protector to be the default. What will
  the effect be on kernel configuration once -fstack-protector is the
  default?
 The kernel has supported building with -fstack-protector since 2.6.19, (at
 least on x86/x86-64).  It's controlled by CONFIG_CC_STACKPROTECTOR and if
 it's disabled then -fno-stack-protector is explicitly added to the command
 line.
On Hardened we disable -fstack-protector* when building kernel and it is done 
with some gcc spec rules that we patch gcc with and it have been working long 
before gcc 4.X versions. It can be turned on with the kernel config option 
CONFIG_CC_STACKPROTECTOR.
/Magnus

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: Improve the security of the default profile

[Magnus Granberg]

onsdag 11 september 2013 04.49.55 skrev  Duncan:

 (Tho jer points out that the parisc arch, among others, won't work with
 that flag at all, and warns to that effect.  So I guess the patch will
 etiher be ifdeffed not to apply on such archs or will be conditionally
 applied in the first place.  The former is I believe preferred as
 conditional patching is considered subpar.)

We only enable -fstack-protector* if the arch is set in SSP_STABLE or 
SSP_UCLIBC_STABLE in the ebuild. For uclibc and ssp it need to be newer then 
.32 and have nptl enable.
/Magnus

Re: [gentoo-dev] Re: Improve the security of the default profile

[Magnus Granberg]

måndag 09 september 2013 21.00.12 skrev  Ryan Hill:
 On Mon, 9 Sep 2013 08:21:35 -0400
 
 Rich Freeman ri...@gentoo.org wrote:
  On Sun, Sep 8, 2013 at 8:06 PM, Ryan Hill dirtye...@gentoo.org wrote:
   So does anyone have any objections to making -fstack-protector the
   default?
   Now is the time to speak up.
  
  So, in this world of all-or-nothing we want people who realize that
  100% protection might not be possible to raise an objection so that we
  end up with 0% protection instead?
 
 No, all I've heard so far is support and wanted to give anyone with an
 opposing viewpoint a chance to speak up.  I support it, but if there are
 any problems we might run into it's best we know about them beforehand, no?
  I wasn't looking for a reason to veto it.
 
  Why not just do the sensible thing (IMHO) and make it a default, and
  then if it doesn't work for an individual package deal with it on an
  individual basis?  We already encourage maintainers to try to get
  custom CFLAGS to work when practical, but when not practical we filter
  them.  I don't see stack protection as any different.  If there is a
  fix, then fix it, and if not, then disable it.  I don't see a lack of
  stack-protection as a reason to keep something out of the tree.
 
 Rich, that's exactly what I'm saying.
 
 We have to make an effort to fix things properly, like we do with any
 supported feature.  That's something I see as one of the key strengths of
 this group we have.  Obviously there are cases where a fix isn't possible
 (glibc and gcc itself are prime examples) and we need to disable it. 
 That's fine.  But we need to discourage people sweeping problems under the
 rug because they're inconvenient, especially when those problems may
 indicate security issues.
 
 I'm just trying to set proper expectations - that this change may break
 people's packages, and they may have to do some work to find out why and how
 to fix it.  I don't like creating more work for people, so I want to be
 sure there is consensus on this first.  So far it sounds like there is.

I did build most of the packages (~14000 packages) in tree when we move from 
gcc 3.X to 4.X with stack protection and some packages didn't work but we fix 
it or added work work arounds to them.  So in short most of the package work 
is allready done. 
/Magnus

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: Improve the security of the default profile

[Jeroen Roovers]

On Sun, 8 Sep 2013 18:06:56 -0600
Ryan Hill dirtye...@gentoo.org wrote:

 So does anyone have any objections to making -fstack-protector the
 default? Now is the time to speak up.

On PARISC you get plenty of warning of how well it's going to work out:

(cc1|gcc|foo): warning: -fstack-protector not supported for this target
[enabled by default]


 jer

Re: [gentoo-dev] Re: Improve the security of the default profile

[Richard Yao]

On 09/08/2013 08:06 PM, Ryan Hill wrote:
 On Sat, 07 Sep 2013 19:08:57 -0400
 Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote:
 
 Personally I think this would be a great stepping stone.  If we add
 - -fstack-protector to 4.8.1 it will improve security (only a little I
 know) and give us an idea of what issues we may have.  After a short
 enjoyment of fixing any issues which come up we could more to
 - -fstack-protector-strong in 4.9.
 
 Okay it won't be available for 4.8.1.  It's going to require a couple minor
 glibc changes and a lot of testing.  A bunch of packages stick workarounds
 behind a hardened USE flag or do things like `filter-flags -fstack-protector`
 which don't actually work (we have to patch the compiler, not just add it to
 the default flags in the profiles or something).  I need to check the
 interactions with hardened's spec files.  And I need to get 4.8.1 out the door
 two weeks ago. Once we fix the fallout from the unmasking I'll get back to 
 this.
 
 I also want to make a comment on the implications of this change that people
 may not have considered.  Bugs caused by -fstack-protector can no longer be
 just dismissed as unsupported, invalid, or assigned to the hardened team and
 forgotten about.  You will be expected to fix them, and `append-flags
 -fno-stack-protector` is not an acceptable fix.  You can't champion for more
 secure defaults and then just disable them when they get in your way.
 
 So does anyone have any objections to making -fstack-protector the default?
 Now is the time to speak up.
 
 
 
 (and for the record I've changed my mind and would like to see this go 
 forward,
 so please stop emailing me)
 
 

A few thoughts:

1. The kernel expects -fno-stack-protector to be the default. What will
the effect be on kernel configuration once -fstack-protector is the default?

2. We should make sure that -fno-stack-protector is a supported CFLAG.
This will make it easier to handle complaints from the vocal minority of
our user base that want every last percentage point of performance.

3. I would like to point out that we are talking about deviating from
upstream behavior and everyone is okay with it. Anyone who thinks we
should stick to upstream when it is not good for us should speak now or
risk being asked where were you when... whenever they try to use
upstream as an excuse to hold back progress. ;)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Improve the security of the default profile

[Rich Freeman]

On Tue, Sep 10, 2013 at 6:41 PM, Richard Yao r...@gentoo.org wrote:
 1. The kernel expects -fno-stack-protector to be the default. What will
 the effect be on kernel configuration once -fstack-protector is the default?

Nothing, since the kernel build system doesn't source make.conf.  If
somebody creates an ebuild that actually installs a kernel then it
might be an issue, though it could be filtered if it is a problem.


 2. We should make sure that -fno-stack-protector is a supported CFLAG.
 This will make it easier to handle complaints from the vocal minority of
 our user base that want every last percentage point of performance.

No reason that it would be any less supported than -fstack-protector
already is.


 3. I would like to point out that we are talking about deviating from
 upstream behavior and everyone is okay with it. Anyone who thinks we
 should stick to upstream when it is not good for us should speak now or
 risk being asked where were you when... whenever they try to use
 upstream as an excuse to hold back progress. ;)

I don't really see this as an issue - in general maintainers are
expected to accommodate reasonable CFLAGS.  This doesn't mean that
arbitrary CFLAGS are supported so much as bugs should be taken
seriously if they're really bugs.  If -fstack-protector causes serious
problems and this is inherent to the nature of the package/etc then
just filter it.  If it causes problems because upstream isn't doing
things right, then this is no different than how things were 10 years
ago when we were stomping out amd64 issues left and right (not working
on amd64 wasn't a reason to mask a package for x86, but we didn't
accept upstream doesn't care about amd64 as an excuse).

Staying close to upstream is a good philosophy in general.  I don't
think that means that we can't have reasonable CFLAGS.  Otherwise we
wouldn't set CFLAGS at all and would just use whatever defaults the
upstream build system applies.  We're a distro - doing integration
work is a value-add, not a sin.  If we aren't doing integration, then
users might as well just do Linux-from-scratch.

Rich

[gentoo-dev] Re: Improve the security of the default profile

[Duncan]

Rich Freeman posted on Tue, 10 Sep 2013 21:17:33 -0400 as excerpted:

 On Tue, Sep 10, 2013 at 6:41 PM, Richard Yao r...@gentoo.org wrote:
 1. The kernel expects -fno-stack-protector to be the default. What will
 the effect be on kernel configuration once -fstack-protector is the
 default?
 
 Nothing, since the kernel build system doesn't source make.conf.  If
 somebody creates an ebuild that actually installs a kernel then it might
 be an issue, though it could be filtered if it is a problem.

If I'm not mistaken, dirtyepic intends to patch gcc directly to enable 
-fstack-protector, changing the default at that level so it'll be used 
unless -fno-stack-protector is in CFLAGS.  At least, that's how I 
interpret (dirtyepic):

'filter-flags -fstack-protector [won't] actually work
(we have to patch the compiler, not just add it to the
default flags in the profiles or something).

Which means that yes, it WILL affect the kernel (and anything else 
separately compiled, unless -fno-stack-protector is given), since it'll 
then be the gentoo-patched gcc default, not in make.conf.

(Tho jer points out that the parisc arch, among others, won't work with 
that flag at all, and warns to that effect.  So I guess the patch will 
etiher be ifdeffed not to apply on such archs or will be conditionally 
applied in the first place.  The former is I believe preferred as 
conditional patching is considered subpar.)

I guess hardened should know what -fstack-protector does to the kernel, 
tho.

But in any case it's certainly worth a news item when it happens, as 
people obviously build a lot of stuff with gcc independent of the tree, 
and I'm sure some of it will break if that becomes the default, so 
letting them know about it with a news item should help avoid at least 
/some/ of the resulting bugs from such a default-change.

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman

[gentoo-dev] Re: Improve the security of the default profile

[Ryan Hill]

On Tue, 10 Sep 2013 18:41:34 -0400
Richard Yao r...@gentoo.org wrote:

 A few thoughts:
 
 1. The kernel expects -fno-stack-protector to be the default. What will
 the effect be on kernel configuration once -fstack-protector is the default?

The kernel has supported building with -fstack-protector since 2.6.19, (at least
on x86/x86-64).  It's controlled by CONFIG_CC_STACKPROTECTOR and if it's
disabled then -fno-stack-protector is explicitly added to the command line.

 2. We should make sure that -fno-stack-protector is a supported CFLAG.
 This will make it easier to handle complaints from the vocal minority of
 our user base that want every last percentage point of performance.

If by supported you mean that they won't be removed by things like strip-flags,
then yes, -fstack-protector -fstack-protector-all -fno-stack-protector and
-fno-stack-protector-all are all on the whitelist.

 3. I would like to point out that we are talking about deviating from
 upstream behavior and everyone is okay with it. Anyone who thinks we
 should stick to upstream when it is not good for us should speak now or
 risk being asked where were you when... whenever they try to use
 upstream as an excuse to hold back progress. ;)

In this case it seems every other distro is already doing this, so we're in
good company.


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

[gentoo-dev] Re: Improve the security of the default profile

[Martin Vaeth]

Ryan Hill dirtye...@gentoo.org wrote:

 You will be expected to fix them, and `append-flags
 -fno-stack-protector` is not an acceptable fix.

I guess there might be some projects with special
assembler code where this is the only possiblity.

For your information, I attach my list of packages
(of about 1400 installed ones) for which I had seen
a reason to exclude them from -fstack-protector
The reasons why they are in the list, I forgot long ago;
might be failure of some version with ARCH=x86 or
ARCH=amd64 or just carefulness like for grub:

app-emulation/wine
dev-libs/klibc
media-gfx/splashutils
sys-apps/texinfo
sys-apps/v86d
sys-boot/grub
sys-devel/llvm

In addition also:

sys-libs/glibc
sys-devel/gcc

(for the latter, I found an old note that
www-plugins/nspluginwrapper failed on amd64
if gcc itself was compiled with -fstack-protector;
I guessed some multilib issue but never examined).

Re: [gentoo-dev] Re: Improve the security of the default profile

[Rich Freeman]

On Sun, Sep 8, 2013 at 8:06 PM, Ryan Hill dirtye...@gentoo.org wrote:
 You will be expected to fix them, and `append-flags
 -fno-stack-protector` is not an acceptable fix.  You can't champion for more
 secure defaults and then just disable them when they get in your way.

Why not?  Surely a system where 99.9% of the packages installed are
hardened is more secure than a system where 0% of the packages
installed are hardened.

 So does anyone have any objections to making -fstack-protector the default?
 Now is the time to speak up.

So, in this world of all-or-nothing we want people who realize that
100% protection might not be possible to raise an objection so that we
end up with 0% protection instead?

Why not just do the sensible thing (IMHO) and make it a default, and
then if it doesn't work for an individual package deal with it on an
individual basis?  We already encourage maintainers to try to get
custom CFLAGS to work when practical, but when not practical we filter
them.  I don't see stack protection as any different.  If there is a
fix, then fix it, and if not, then disable it.  I don't see a lack of
stack-protection as a reason to keep something out of the tree.

Rich

[gentoo-dev] Re: Improve the security of the default profile

[Ryan Hill]

On Mon, 9 Sep 2013 08:21:35 -0400
Rich Freeman ri...@gentoo.org wrote:

 On Sun, Sep 8, 2013 at 8:06 PM, Ryan Hill dirtye...@gentoo.org wrote:
  So does anyone have any objections to making -fstack-protector the default?
  Now is the time to speak up.
 
 So, in this world of all-or-nothing we want people who realize that
 100% protection might not be possible to raise an objection so that we
 end up with 0% protection instead?

No, all I've heard so far is support and wanted to give anyone with an opposing
viewpoint a chance to speak up.  I support it, but if there are any problems we
might run into it's best we know about them beforehand, no?  I wasn't looking
for a reason to veto it.
 
 Why not just do the sensible thing (IMHO) and make it a default, and
 then if it doesn't work for an individual package deal with it on an
 individual basis?  We already encourage maintainers to try to get
 custom CFLAGS to work when practical, but when not practical we filter
 them.  I don't see stack protection as any different.  If there is a
 fix, then fix it, and if not, then disable it.  I don't see a lack of
 stack-protection as a reason to keep something out of the tree.

Rich, that's exactly what I'm saying.

We have to make an effort to fix things properly, like we do with any supported
feature.  That's something I see as one of the key strengths of this group we
have.  Obviously there are cases where a fix isn't possible (glibc and gcc
itself are prime examples) and we need to disable it.  That's fine.  But we
need to discourage people sweeping problems under the rug because they're
inconvenient, especially when those problems may indicate security issues.

I'm just trying to set proper expectations - that this change may break
people's packages, and they may have to do some work to find out why and how to
fix it.  I don't like creating more work for people, so I want to be sure there
is consensus on this first.  So far it sounds like there is.


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Improve the security of the default profile

[Peter Stuge]

Ryan Hill wrote:
 I don't like creating more work for people, so I want to be sure
 there is consensus on this first.  So far it sounds like there is.

I think there will come enough objections, but only down the road,
and only from people who don't want to care about quality.

Don't let that stop the improvements from happening.


Thanks

//Peter


pgpVL39G_2RCE.pgp
Description: PGP signature

[gentoo-dev] Re: Improve the security of the default profile

[Martin Vaeth]

Ryan Hill dirtye...@gentoo.org wrote:

  * -Wl,-z,relro
  Enabled by default since binutils 2.18

 This gives its real impact on secutiry only when combined with

 * -Wl,-z,now

 The latter is not enabled by default AFAIK.

 That's a bit misleading.  Immediate binding does allow the GOT to be made
 readonly but relro does a lot more than that.

It is somewhat pointless if not everything is readonly:
In analogy, relro without now is a bit like making all your files
readonly but leaving write-permissions on the directories.
It only helps against too poorly designed exploits of corresponding
bugs.

 In any case this is a firm no.
 The increase in loading times for apps that link lots of libraries is
 significant (if it wasn't, we wouldn't need lazy loading :p).

You get the same delay for lazy linking, only not necessarily
everything immediately when the application starts up.
And even then it is only faster (at startup) if only very few symbols
are needed near the beginning.

Quite the opposite, total time of loading huge projects like
kde or libreoffice can even be faster with now, since you do
not need administration overhead for keeping track of resolving.
I did not realize a measurable difference for kde and libreoffice
even on my slow machines - random things like location on harddisk
apparently had a much bigger impact on startup.
Please really try before you fix your opinion.

 * -Wl,-z,noexecstack

 Well, portage will already tell you if your package installed any
 binaries with executable stacks

For some it did warn - otherwise I would not have found the bug.
But for some it did not.  However, I cannot recall which packages
these were, and I did not examine why.
Anyway, since this probably only concerns certain gcc versions
with -flto, I guess that we need not discuss much about this flag.

 However, isn't it time to use gnu now for all users? [...]

 Sure, but the sysv hash is teeny and backward compatibility is
 always nice if it's next to free.

But it is not completely free, and the majority of users
will never have any need for it - in factõ I do not know
any use-case, but of course I do not know all ancient software
sitting around somewhere.
Those few who need it can add the option without difficulties.

[gentoo-dev] Re: Improve the security of the default profile

[Martin Vaeth]

Ryan Hill dirtye...@gentoo.org wrote:
 Martin Vaeth va...@mathematik.uni-wuerzburg.de wrote:
 
  * -fstack-protector{-all}
  No thank you.  -fstack-protector has very limited coverage

 I'd say it covers most cases where bugs can be made, [...]

 The numbers I've seen show a maximum of 5% coverage for code that has a
 large number of functions containing char arrays on the stack.

If you have no local array on the stack, it is rather hard to write
accidentally(!) code in the function which corrupts the stack.
(It still is possible e.g. through bad casting, but it is rather
unlikely that this happens by accident).
So coverage of these functions covers most cases of accidental bugs.
Of course, as Ciaranm already mentioned, there is no compiler flag
which transforms unsafe code into safe one, but if even just one or
two security bugs can be avoid this way, it was worth to add
this flag IMHO.

 Most code doesn't fall into that category.

Isn't this good news? It means most code will not get *any*
penalty with -fstack-protector.

Re: [gentoo-dev] Re: Improve the security of the default profile

[Hinnerk van Bruinehsen]

On Sat, Sep 07, 2013 at 07:12:04PM -0400, Rich Freeman wrote:
 On Sat, Sep 7, 2013 at 7:08 PM, Rick Zero_Chaos Farina
 zeroch...@gentoo.org wrote:
  Personally I'm using the hardened profile already and find the
  performance penalties negligible for a desktop user, and someone trying
  to run realtime on defaults is likely suicidal anyway.
 
 I suspect what keeps people away from hardened isn't the performance,
 but the risk of compatibility issues.  Most operations these days
 aren't CPU-bound, but getting something like RBAC to work right is
 fairly involved...
 
 Rich

Hi,

from a longtime user perspective: I'm using hardened on desktops since about 
three or
four years now and I can't remember any issues that were caused by the
toolchain. Performance loss is imho negligible even on low powered systems like 
an
atom netbook or my Raspberry Pi (I'm not saying, that there is none, but it's
nothing dramatical).
RBAC, SELinux or a PaX enabled kernel is a completly other matter (in terms of
breakage and usability) but this thread was about toolchain not kernel, wasn't 
it?

WKR
Hinnerk


signature.asc
Description: Digital signature

[gentoo-dev] Re: Improve the security of the default profile

[Ryan Hill]

On Sat, 07 Sep 2013 19:08:57 -0400
Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote:

 Personally I think this would be a great stepping stone.  If we add
 - -fstack-protector to 4.8.1 it will improve security (only a little I
 know) and give us an idea of what issues we may have.  After a short
 enjoyment of fixing any issues which come up we could more to
 - -fstack-protector-strong in 4.9.

Okay it won't be available for 4.8.1.  It's going to require a couple minor
glibc changes and a lot of testing.  A bunch of packages stick workarounds
behind a hardened USE flag or do things like `filter-flags -fstack-protector`
which don't actually work (we have to patch the compiler, not just add it to
the default flags in the profiles or something).  I need to check the
interactions with hardened's spec files.  And I need to get 4.8.1 out the door
two weeks ago. Once we fix the fallout from the unmasking I'll get back to this.

I also want to make a comment on the implications of this change that people
may not have considered.  Bugs caused by -fstack-protector can no longer be
just dismissed as unsupported, invalid, or assigned to the hardened team and
forgotten about.  You will be expected to fix them, and `append-flags
-fno-stack-protector` is not an acceptable fix.  You can't champion for more
secure defaults and then just disable them when they get in your way.

So does anyone have any objections to making -fstack-protector the default?
Now is the time to speak up.



(and for the record I've changed my mind and would like to see this go forward,
so please stop emailing me)


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

[gentoo-dev] Re: Improve the security of the default profile

[Ryan Hill]

On Sun, 8 Sep 2013 11:05:16 + (UTC)
Martin Vaeth va...@mathematik.uni-wuerzburg.de wrote:

 Ryan Hill dirtye...@gentoo.org wrote:

  In any case this is a firm no.
  The increase in loading times for apps that link lots of libraries is
  significant (if it wasn't, we wouldn't need lazy loading :p).
 
 You get the same delay for lazy linking, only not necessarily
 everything immediately when the application starts up.
 And even then it is only faster (at startup) if only very few symbols
 are needed near the beginning.
 
 Quite the opposite, total time of loading huge projects like
 kde or libreoffice can even be faster with now, since you do
 not need administration overhead for keeping track of resolving.
 I did not realize a measurable difference for kde and libreoffice
 even on my slow machines - random things like location on harddisk
 apparently had a much bigger impact on startup.
 Please really try before you fix your opinion.

I'm basing my opinion on the experiences reported by other distros, by
openwall, and by our own hardened team.  In any case my opinion doesn't really
matter because in the end since I'm not the one who gets to make that
decision.  I misrepresented that and I apologize.  I would still be against
making this change.

  However, isn't it time to use gnu now for all users? [...]
 
  Sure, but the sysv hash is teeny and backward compatibility is
  always nice if it's next to free.
 
 But it is not completely free, and the majority of users
 will never have any need for it - in factõ I do not know
 any use-case, but of course I do not know all ancient software
 sitting around somewhere.
 Those few who need it can add the option without difficulties.

FWIW I agree but I am not the binutils maintainer.


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Improve the security of the default profile

[Parker Schmitt]

Perhaps a hardened desktop profile might be nice. Possibly even an selinux
profile with the popular WMs. From what I remember users of the server
profile are given a warning to switch to hardened though it would be nice
to add hardened options to other specialized profiles.


On Sat, Sep 7, 2013 at 3:48 AM, Rick Zero_Chaos Farina 
zeroch...@gentoo.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 09/05/2013 07:06 AM, Mike Frysinger wrote:
  On Thursday 05 September 2013 06:13:28 Agostino Sarubbo wrote:
  during an irc debate, me and other people just noticed that the default
  profile could use more flags to enhance the security.
 
  An hint is here:
  https://wiki.ubuntu.com/ToolChain/CompilerFlags
 
  Please argue about what we _don't_ use.
 
  the only thing we don't use by default is SSP.  and we have hardened for
 that.
 
  fairly certain the other flags we've been using in Gentoo for years.
  -mike
 

 Since I don't see this in the profile and I know almost nothing about
 how the toolchain works, perhaps you could grace us with how to see the
 fact that we've been using in Gentoo for years :-)

 Thanks,
 Zero
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.20 (GNU/Linux)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQIcBAEBAgAGBQJSKqIYAAoJEKXdFCfdEflKCwkP/Rdlo2rk+g8qyfB9SlsFgoP0
 4b+/qkB8WmwNBEURhR7kwF/SJa6kh0BOcorz33e/YO4jayn/yW1ve36HrKOGR52G
 56oNWWtRYzsiscObpOVxf+JM9EMm2RVrhfM1Z9FIP8pTFS8gj31fR8caPJssjUGv
 xl0wSUahs1+q44xOX+NB+7y47nhrjwfq2OTUHsekMdOWt43MoLp86qEMJKlPFG9a
 djEpkshTpE2pZZMQ8jGGASmITcWlHhuipeWkwDCblcxMMCWgFr+CfovEqJXeoz5I
 jI4rtpe4QNl7QA+eXY1fygiAiVgx15BYq2SIBC51AluvVgaYRw8ANr8qSUhCakXM
 Af49vhzp8/Id3/aytOrllprucPHTICMARKbYhAJyGtfJtKkQ3iGHHOlrIN2ufnrO
 gO/EZUqb+NRlHrv845a0HQA3zmYDNBJw5zu6GymV4aMsUcVQE/uSbqAZ7BxuWlV2
 LxLvE9pn48WvcvBYp4R36DRQg955D34GKI1VRojgESsyLIgq4Q0wLjarY1fsG4O/
 iUZRyXOI5erVCiOGey42kCr19fw1ta35XtKrEQPwWJkb2na1RB7PHbGBdVBlU/Lq
 mLAWFSCwocg+wNBuBWcpJlFdLV4eQYxSqyTqeFdxYBv9qxvqqLzkGUxqDy8L4bAT
 KglCdavI5Y2UBcFuv4/w
 =yb4E
 -END PGP SIGNATURE-

[gentoo-dev] Re: Improve the security of the default profile

[Ryan Hill]

On Thu, 05 Sep 2013 12:13:28 +0200
Agostino Sarubbo a...@gentoo.org wrote:

 Hello,
 
 during an irc debate, me and other people just noticed that the default 
 profile could use more flags to enhance the security.
 
 An hint is here:
 https://wiki.ubuntu.com/ToolChain/CompilerFlags
 
 Please argue about what we _don't_ use.
 
 Note: please CC me in your response.

* -fstack-protector{-all}
No thank you.  -fstack-protector has very limited coverage (which is why
Ubuntu felt they needed to mess with the min size) and -fstack-protector-all
has enough overhead that every distro that experimented with it dropped it in
the end.  If security is important enough to you that you are willing to take
the hit then you should be using hardened where it's the default.

There is a new option, -fstack-protector-strong, that's intended to be a
balance between the two extremes and something that distros can enable by
default.  It was just added to mainline so it should be in GCC 4.9.  So let's
revisit this a couple years down the line.

* -D_FORTIFY_SOURCE=2
Enabled by default since gcc-4.5.0 (patch)

* -Wformat -Wformat-security
Enabled by default since gcc 4.3.3 (patch)

* -Wl,-z,relro
Enabled by default since binutils 2.18 (and as far back as 2.15 for the HJL
releases). (patch)

* -Wl,--hash-style={both,gnu}
Enabled by default since binutils 2.18 except on mips where it is unsupported.
(patch sets it to both, developer profiles set it to gnu for ignored LDFLAGs
detection)

* -Wl,--no-copy-dt-needed-entries/-Wl,--no-add-needed
Enabled by default since binutils 2.22. (upstream default)

* -Wl,--as-needed
Enabled by default since July 2010 (in profiles).  I think this is the upstream
default now as well.

In addition to these we also enable -Wtrampolines and warn on DT_TEXTRELs.



-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

[gentoo-dev] Re: Improve the security of the default profile

[Martin Vaeth]

Ryan Hill dirtye...@gentoo.org wrote:

 * -fstack-protector{-all}
 No thank you.  -fstack-protector has very limited coverage

I'd say it covers most cases where bugs can be made,
practically without a severe impact on execution time or code size.
In contrast, -fstack-protector-all should be left to hardened, since
its impact is unacceptable to e.g. multimedia systems - the
protection is probably over-the-top for normal users.
I'd vote for enabling -fstack-protector by default:
I am using it since many years (though I do not use hardened profile,
since -fstack-protector-all had too much a performance impact for me).

 -fstack-protector-strong

One can later still change to this when =gcc-4.9 is available in stable.

 * -Wl,-z,relro
 Enabled by default since binutils 2.18

This gives its real impact on secutiry only when combined with

* -Wl,-z,now

The latter is not enabled by default AFAIK.
The latter can slightly decrease load times, but repeated starting is
usually even faster with it. Thus, performance impact is somewhat
balanced, but it increases security slightly (though it would need
a good expert to exploit the problems when it is not used).
I am strongly suggesting to use -Wl,-z,now (and filter it on some
packages which won't work with it like xorg drivers).
I am also using this flag for many years (filtering certain packages;
if desired, I can post a list).

I would like to suggest also another flag

* -Wl,-z,noexecstack

This should be the default, but e.g. some broken gcc versions
forgot this default when using -flto.
I am using this flag since I realized this -flto bug and never
had any problems with it.

 * -Wl,--hash-style=3D{both,gnu}

I don't know what this has to do with security.
However, isn't it time to use gnu now for all users?  Except for
very strange binary-only code it should not cause any problems.
The majority of users would not realize a difference but profit
from smaller binaries.

 * -Wl,--as-needed

The impact on security is at most rather implicit, if at all.

[gentoo-dev] Re: Improve the security of the default profile

[Martin Vaeth]

Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:

 Security does not come from the compiler. There is no compiler flag
 that magically makes insecure code secure.

But there are flags which can catch some frequent code bugs which
perhaps some less careful upstream overlooked or is not aware of.
Moreover, the flags can cause some code bugs to have less impact
on the security of the system as a whole.

Re: [gentoo-dev] Re: Improve the security of the default profile

[Rich Freeman]

On Sat, Sep 7, 2013 at 2:10 PM, Martin Vaeth
va...@mathematik.uni-wuerzburg.de wrote:
 Ryan Hill dirtye...@gentoo.org wrote:

 * -fstack-protector{-all}
 No thank you.  -fstack-protector has very limited coverage

 I'd say it covers most cases where bugs can be made,
 practically without a severe impact on execution time or code size.
 In contrast, -fstack-protector-all should be left to hardened, since
 its impact is unacceptable to e.g. multimedia systems - the
 protection is probably over-the-top for normal users.
 I'd vote for enabling -fstack-protector by default:
 I am using it since many years (though I do not use hardened profile,
 since -fstack-protector-all had too much a performance impact for me).

 -fstack-protector-strong

 One can later still change to this when =gcc-4.9 is available in stable.

++, ++

No doubt stack-protector-strong is better than stack-protector, but
stack-protector is still better than nothing, and nothing is the
current default.

Improvements don't need to be perfect - they just need to be improvements.

Rich

Re: [gentoo-dev] Re: Improve the security of the default profile

[Pacho Ramos]

El sáb, 07-09-2013 a las 14:37 -0400, Rich Freeman escribió:
 On Sat, Sep 7, 2013 at 2:10 PM, Martin Vaeth
 va...@mathematik.uni-wuerzburg.de wrote:
  Ryan Hill dirtye...@gentoo.org wrote:
 
  * -fstack-protector{-all}
  No thank you.  -fstack-protector has very limited coverage
 
  I'd say it covers most cases where bugs can be made,
  practically without a severe impact on execution time or code size.
  In contrast, -fstack-protector-all should be left to hardened, since
  its impact is unacceptable to e.g. multimedia systems - the
  protection is probably over-the-top for normal users.
  I'd vote for enabling -fstack-protector by default:
  I am using it since many years (though I do not use hardened profile,
  since -fstack-protector-all had too much a performance impact for me).
 
  -fstack-protector-strong
 
  One can later still change to this when =gcc-4.9 is available in stable.
 
 ++, ++
 
 No doubt stack-protector-strong is better than stack-protector, but
 stack-protector is still better than nothing, and nothing is the
 current default.
 
 Improvements don't need to be perfect - they just need to be improvements.
 
 Rich
 

Is there any kind of information about performance penalty of
-fstack-protector? I have googled some time and there are various
estimations (from ~2 to ~8%), but I have no idea what have they checked
exactly. Also, multiple comments here refer to not severe impact that
looks to me like it will have impact but not too much :/. For some
recent computers I would probably use it, but for older ones, I am not
sure if will be happy with that additional impact :|

Thanks for the info

Re: [gentoo-dev] Re: Improve the security of the default profile

[Rick Zero_Chaos Farina]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/07/2013 01:25 PM, Ryan Hill wrote:
 On Thu, 05 Sep 2013 12:13:28 +0200
 Agostino Sarubbo a...@gentoo.org wrote:
 
 Hello,

 during an irc debate, me and other people just noticed that the default 
 profile could use more flags to enhance the security.

 An hint is here:
 https://wiki.ubuntu.com/ToolChain/CompilerFlags

 Please argue about what we _don't_ use.

 Note: please CC me in your response.
 
 * -fstack-protector{-all}
 No thank you.  -fstack-protector has very limited coverage (which is why
 Ubuntu felt they needed to mess with the min size) and -fstack-protector-all
 has enough overhead that every distro that experimented with it dropped it in
 the end.  If security is important enough to you that you are willing to take
 the hit then you should be using hardened where it's the default.
 
 There is a new option, -fstack-protector-strong, that's intended to be a
 balance between the two extremes and something that distros can enable by
 default.  It was just added to mainline so it should be in GCC 4.9.  So let's
 revisit this a couple years down the line.
 
 * -D_FORTIFY_SOURCE=2
 Enabled by default since gcc-4.5.0 (patch)
 
 * -Wformat -Wformat-security
 Enabled by default since gcc 4.3.3 (patch)
 
 * -Wl,-z,relro
 Enabled by default since binutils 2.18 (and as far back as 2.15 for the HJL
 releases). (patch)
 
 * -Wl,--hash-style={both,gnu}
 Enabled by default since binutils 2.18 except on mips where it is unsupported.
 (patch sets it to both, developer profiles set it to gnu for ignored 
 LDFLAGs
 detection)
 
 * -Wl,--no-copy-dt-needed-entries/-Wl,--no-add-needed
 Enabled by default since binutils 2.22. (upstream default)
 
 * -Wl,--as-needed
 Enabled by default since July 2010 (in profiles).  I think this is the 
 upstream
 default now as well.
 
 In addition to these we also enable -Wtrampolines and warn on DT_TEXTRELs.
 
 
 
Thank you so much for spelling it out for us. I don't even know where to
begin looking for how some of this stuff is enabled so you telling us
what is enabled makes a huge difference.

I'm semi-familiar with -fstack-protector-strong and I look forward to
revisiting that at a later date (and I'd love to help do the testing so
hold me to if if you like).

Thanks,
Zero
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSK4OVAAoJEKXdFCfdEflK/N4P/3zPgskznIRwgkEVmqJgOGKL
jUQSva6zOptAGUX3TBdmxppERiWwRR+qh00+JdRP34rH+yEaU3THyjoSreTzunXW
+oFcBeNR6qiiYGTKoGwQTtM0gxbkFvCx6fe/AAGkwYinTrorL8eo3VmnjBvzvBP4
Gmw138SMA/JGLG4A2s5vQBlBZlwvFOyNwP6RzAt9SoNsYVuskDMnFiw77pnqbEYT
OwdkGRwG29995L+p3O4lbsj7UjLx7S4/SpFfh9OK2EObQ7IKTb4M/y7TUv4vMSxG
b4uEtNRH2ymr/u8kHOLeVBFBvKbtB35hE1ubLN0ugtuAvQKyD/tECC1msXuKidqi
vjrhxqtMG4c9+7yY1My0S9CkFqR015ReiC9mFgbVO588XKDOCT7QtcCqGVfvEOrS
/CNh0qMS5JeBwAya4rmiZpGkc0LTW3rjzLsJfu3sVAd6nvHh1923gSpnJpnd7u9X
EpGORP29NUyu3W7zggJm36JEX+pNvTlG1NmR7ux9NWVFKVfUVBU/wAnfHmCpTHo8
O8FI2Z3GlEwXNXL9nvDn7DJRVsC4TOl6SbHteVRY0soGmyoQhf9I1D0idLFLv88k
HHeTzhVt0dl0OiWBs8n7AU42bA/QMUvLF4wUJM+zBjkZHNgWvbL895eyAOJdGAyo
2HEguV/K746RLBHhRRTe
=gq9h
-END PGP SIGNATURE-

[gentoo-dev] Re: Improve the security of the default profile

[Martin Vaeth]

Pacho Ramos pa...@gentoo.org wrote:

 Is there any kind of information about performance penalty of
 -fstack-protector? I have googled some time and there are various
 estimations (from ~2 to ~8%), but I have no idea what have they checked
 exactly.

This depends extremely on the code: Most functions will be unchanged,
and only a few functions with possibly dangerous code get a fixed
impact whenever they are called. Whether they are called frequently
or not cannot be said in general.

 looks to me like it will have impact but not too much :/

Of course, it will have impact, but it is more theoretical than practical.

 For some recent computers I would probably use it,
 but for older ones, I am not sure if will be happy
 with that additional impact :|

On my old Pentium III laptop it makes no difference for my applications
which can be felt. Of course, if you have a special time-critical
application which just was on the limit, things might be different.
However,in such cases you would also use things like -DNDEBUG which one
would not choose as a default just because it gives some minimal
performance enhancement.

[gentoo-dev] Re: Improve the security of the default profile

[Ryan Hill]

On Sat, 7 Sep 2013 18:10:42 + (UTC)
Martin Vaeth va...@mathematik.uni-wuerzburg.de wrote:

 Ryan Hill dirtye...@gentoo.org wrote:
 
  * -fstack-protector{-all}
  No thank you.  -fstack-protector has very limited coverage
 
 I'd say it covers most cases where bugs can be made,
 practically without a severe impact on execution time or code size.

The numbers I've seen show a maximum of 5% coverage for code that has a large
number of functions containing char arrays on the stack.  Most code doesn't fall
into that category.  Coverage of perl was 0.5%, xorg 5%, kernel 3%.  Those are
really old numbers though.  The most recent I've seen is Chromium's coverage is
2%.  There is an upper bound of 8% performance overhead using -fstack-protector
according to the design spec.  If you guys are okay with that then we can try
enabling it for 4.8.1.

  * -Wl,-z,relro
  Enabled by default since binutils 2.18
 
 This gives its real impact on secutiry only when combined with
 
 * -Wl,-z,now
 
 The latter is not enabled by default AFAIK.

That's a bit misleading.  Immediate binding does allow the GOT to be made
readonly but relro does a lot more than that.  In any case this is a firm no.
The increase in loading times for apps that link lots of libraries is
significant (if it wasn't, we wouldn't need lazy loading :p).  If you want full
relro, enable it yourself or use hardened.

 I would like to suggest also another flag
 
 * -Wl,-z,noexecstack
 
 This should be the default, but e.g. some broken gcc versions
 forgot this default when using -flto.
 I am using this flag since I realized this -flto bug and never
 had any problems with it.

Well, portage will already tell you if your package installed any binaries with
executable stacks and I don't see many of those warnings that aren't binary
packages so I think we're good.

 
  * -Wl,--hash-style={both,gnu}
 
 I don't know what this has to do with security.

I'm just responding to the list on the Ubuntu page.

 However, isn't it time to use gnu now for all users?  Except for
 very strange binary-only code it should not cause any problems.
 The majority of users would not realize a difference but profit
 from smaller binaries.

Sure, but the sysv hash is teeny and backward compatibility is always nice if
it's next to free.

Here are some more resources if anyone is interested:

https://wiki.debian.org/Hardening
https://bugs.archlinux.org/task/18864
https://wiki.gentoo.org/wiki/Project:Hardened/GNU_stack_quickstart
http://tk-blog.blogspot.ca/2009/02/relro-not-so-well-known-memory.html

-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Improve the security of the default profile

[Rick Zero_Chaos Farina]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/07/2013 05:11 PM, Ryan Hill wrote:
 On Sat, 7 Sep 2013 18:10:42 + (UTC)
 Martin Vaeth va...@mathematik.uni-wuerzburg.de wrote:
 
 Ryan Hill dirtye...@gentoo.org wrote:

 * -fstack-protector{-all}
 No thank you.  -fstack-protector has very limited coverage

 I'd say it covers most cases where bugs can be made,
 practically without a severe impact on execution time or code size.
 
 The numbers I've seen show a maximum of 5% coverage for code that has a large
 number of functions containing char arrays on the stack.  Most code doesn't 
 fall
 into that category.  Coverage of perl was 0.5%, xorg 5%, kernel 3%.  Those are
 really old numbers though.  The most recent I've seen is Chromium's coverage 
 is
 2%.  There is an upper bound of 8% performance overhead using 
 -fstack-protector
 according to the design spec.  If you guys are okay with that then we can try
 enabling it for 4.8.1.

Personally I think this would be a great stepping stone.  If we add
- -fstack-protector to 4.8.1 it will improve security (only a little I
know) and give us an idea of what issues we may have.  After a short
enjoyment of fixing any issues which come up we could more to
- -fstack-protector-strong in 4.9.

Personally I'm using the hardened profile already and find the
performance penalties negligible for a desktop user, and someone trying
to run realtime on defaults is likely suicidal anyway.

Thanks,
Zero

 
 * -Wl,-z,relro
 Enabled by default since binutils 2.18

 This gives its real impact on secutiry only when combined with

 * -Wl,-z,now

 The latter is not enabled by default AFAIK.
 
 That's a bit misleading.  Immediate binding does allow the GOT to be made
 readonly but relro does a lot more than that.  In any case this is a firm no.
 The increase in loading times for apps that link lots of libraries is
 significant (if it wasn't, we wouldn't need lazy loading :p).  If you want 
 full
 relro, enable it yourself or use hardened.
 
 I would like to suggest also another flag

 * -Wl,-z,noexecstack

 This should be the default, but e.g. some broken gcc versions
 forgot this default when using -flto.
 I am using this flag since I realized this -flto bug and never
 had any problems with it.
 
 Well, portage will already tell you if your package installed any binaries 
 with
 executable stacks and I don't see many of those warnings that aren't binary
 packages so I think we're good.
 

 * -Wl,--hash-style={both,gnu}

 I don't know what this has to do with security.
 
 I'm just responding to the list on the Ubuntu page.
 
 However, isn't it time to use gnu now for all users?  Except for
 very strange binary-only code it should not cause any problems.
 The majority of users would not realize a difference but profit
 from smaller binaries.
 
 Sure, but the sysv hash is teeny and backward compatibility is always nice if
 it's next to free.
 
 Here are some more resources if anyone is interested:
 
 https://wiki.debian.org/Hardening
 https://bugs.archlinux.org/task/18864
 https://wiki.gentoo.org/wiki/Project:Hardened/GNU_stack_quickstart
 http://tk-blog.blogspot.ca/2009/02/relro-not-so-well-known-memory.html
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSK7IJAAoJEKXdFCfdEflKdIkP/3dQpOuzSlzMcXD68oD2L5HP
1ZrgAZzPkBKUOEvlH6WuCIC48k0GdeWCojz4kgo6LM8O3rsn3WRBO1iWbUjSxFja
P8W6bsLJw4t9Tuwk6GJvW0blM66lwQub2+MOynv8DRKloIoQ7yJZmlS1MurcNZFk
AQhl+3xoBpwkXIoR5zCJg0ipMuLV5PdqrtFp7VlPrs3yQfuFw/dxU2+sjo6Kau4a
WvPHzZWco328jVwPHh9F+nFD4F8jKXmBKwy3moOwFkh5a9XnJH3amG7sK37oNWVx
OkQ1pRPaBUyTvNOpA83kQFoa0I6ZWDLK/sCtxtNjadGBKHRwdMWBGN+iZWYH3CEv
uNJBxrJkMbubEpvRK/3nf+fvfa8ChNBbbZlOxyaZ50UCT7KtQ9S0VQWVjYuNYLQy
k9Yzc9jNcEilY5ux0RYqaAosZKso3ePkmbBfZLUs8E2F2C7NwJkhj5tv0AGAWt+n
kN+9MlL/rQhlVh6FtobZVs2DfVxfC87vA0MKJFOoqsOR1w5p2f+mKAUMqJi4jEHJ
ElyJdgIP3KegBIRVp1N9URofA8mIA1fh0Ef3JMx6020LVFXBuO5lihtrLCLR+t5h
PmHrmfbLS1SS/qsN/OavGaYjOhMExcJwNFnuguhNFIcQUdLUmTRzXf7uQ9b1zrbg
ZxLySFNAMubNMQf9Q9j/
=TPkK
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: Improve the security of the default profile

[Rick Zero_Chaos Farina]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/05/2013 07:06 AM, Mike Frysinger wrote:
 On Thursday 05 September 2013 06:13:28 Agostino Sarubbo wrote:
 during an irc debate, me and other people just noticed that the default
 profile could use more flags to enhance the security.

 An hint is here:
 https://wiki.ubuntu.com/ToolChain/CompilerFlags

 Please argue about what we _don't_ use.
 
 the only thing we don't use by default is SSP.  and we have hardened for that.
 
 fairly certain the other flags we've been using in Gentoo for years.
 -mike
 

Since I don't see this in the profile and I know almost nothing about
how the toolchain works, perhaps you could grace us with how to see the
fact that we've been using in Gentoo for years :-)

Thanks,
Zero
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSKqIYAAoJEKXdFCfdEflKCwkP/Rdlo2rk+g8qyfB9SlsFgoP0
4b+/qkB8WmwNBEURhR7kwF/SJa6kh0BOcorz33e/YO4jayn/yW1ve36HrKOGR52G
56oNWWtRYzsiscObpOVxf+JM9EMm2RVrhfM1Z9FIP8pTFS8gj31fR8caPJssjUGv
xl0wSUahs1+q44xOX+NB+7y47nhrjwfq2OTUHsekMdOWt43MoLp86qEMJKlPFG9a
djEpkshTpE2pZZMQ8jGGASmITcWlHhuipeWkwDCblcxMMCWgFr+CfovEqJXeoz5I
jI4rtpe4QNl7QA+eXY1fygiAiVgx15BYq2SIBC51AluvVgaYRw8ANr8qSUhCakXM
Af49vhzp8/Id3/aytOrllprucPHTICMARKbYhAJyGtfJtKkQ3iGHHOlrIN2ufnrO
gO/EZUqb+NRlHrv845a0HQA3zmYDNBJw5zu6GymV4aMsUcVQE/uSbqAZ7BxuWlV2
LxLvE9pn48WvcvBYp4R36DRQg955D34GKI1VRojgESsyLIgq4Q0wLjarY1fsG4O/
iUZRyXOI5erVCiOGey42kCr19fw1ta35XtKrEQPwWJkb2na1RB7PHbGBdVBlU/Lq
mLAWFSCwocg+wNBuBWcpJlFdLV4eQYxSqyTqeFdxYBv9qxvqqLzkGUxqDy8L4bAT
KglCdavI5Y2UBcFuv4/w
=yb4E
-END PGP SIGNATURE-

[gentoo-dev] Re: Improve the security of the default profile

[Mike Frysinger]

On Thursday 05 September 2013 06:13:28 Agostino Sarubbo wrote:
 during an irc debate, me and other people just noticed that the default
 profile could use more flags to enhance the security.
 
 An hint is here:
 https://wiki.ubuntu.com/ToolChain/CompilerFlags
 
 Please argue about what we _don't_ use.

the only thing we don't use by default is SSP.  and we have hardened for that.

fairly certain the other flags we've been using in Gentoo for years.
-mike


signature.asc
Description: This is a digitally signed message part.