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

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

[Agostino Sarubbo]

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.
-- 
Agostino Sarubbo
Gentoo Linux Developer

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

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]

On Thu, 05 Sep 2013 12:13:28 +0200
Agostino Sarubbo <ago@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.

What I wonder about here is at which cost this does come, when looking
at the fstack-protector then I see that it "emits extra code"; so, now
the question is what kind of overhead this causes.

I am pretty sure security might not be that important on a real time
system that perhaps isn't connected to the internet; so, besides making
it the default, we might want to introduce the necessary means to turn
it off again, by the very least perhaps documentation would suffice.

Do you intend to discuss that flag or more generally any security flag?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Agostino Sarubbo]

On Thursday 05 September 2013 12:47:01 Tom Wijsman wrote:
> What I wonder about here is at which cost this does come, when looking
> at the fstack-protector then I see that it "emits extra code"; so, now
> the question is what kind of overhead this causes.

We use -fstack-protector-all in the hardened profile, so it is not unknown at 
all.

> I am pretty sure security might not be that important on a real time
> system that perhaps isn't connected to the internet; so, besides making
> it the default, we might want to introduce the necessary means to turn
> it off again, by the very least perhaps documentation would suffice.
> 
> Do you intend to discuss that flag or more generally any security flag?

I just want to point out the thread because other people will have something 
to say about.
-- 
Agostino Sarubbo
Gentoo Linux Developer

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

[Sergey Popov]

[-- Attachment #1: Type: text/plain, Size: 1614 bytes --]

05.09.2013 14:47, Tom Wijsman пишет:
> On Thu, 05 Sep 2013 12:13:28 +0200
> Agostino Sarubbo <ago@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.
> 
> What I wonder about here is at which cost this does come, when looking
> at the fstack-protector then I see that it "emits extra code"; so, now
> the question is what kind of overhead this causes.
> 
> I am pretty sure security might not be that important on a real time
> system that perhaps isn't connected to the internet; so, besides making
> it the default, we might want to introduce the necessary means to turn
> it off again, by the very least perhaps documentation would suffice.
> 
> Do you intend to discuss that flag or more generally any security flag?
> 

Regarding -fstack-protector - it can be used at least in hardened
profiles(but i have some sort of bad expirience with it and uclibc[1]).
Also kernel has apropriate option to enable it during build.

However, i am not skilled with GCC internals, so i can say nothing about
perfomance impact this flag may have. Maybe toolchain guys can bring
light on this ;-)

[1] - https://bugs.gentoo.org/show_bug.cgi?id=470608

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 479 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1361 bytes --]

On Thu, 05 Sep 2013 12:54:27 +0200
Agostino Sarubbo <ago@gentoo.org> wrote:

> On Thursday 05 September 2013 12:47:01 Tom Wijsman wrote:
> > What I wonder about here is at which cost this does come, when
> > looking at the fstack-protector then I see that it "emits extra
> > code"; so, now the question is what kind of overhead this causes.
> 
> We use -fstack-protector-all in the hardened profile, so it is not
> unknown at all.
> 
> > I am pretty sure security might not be that important on a real time
> > system that perhaps isn't connected to the internet; so, besides
> > making it the default, we might want to introduce the necessary
> > means to turn it off again, by the very least perhaps documentation
> > would suffice.
> > 
> > Do you intend to discuss that flag or more generally any security
> > flag?
> 
> I just want to point out the thread because other people will have
> something to say about.

Yes, I am aware of that, I am not saying it is unknown; but I am
wondering about those questions: What kind of overhead does this cause?
Do you intend to discuss that flag or more generally any security flag?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Agostino Sarubbo]

On Thursday 05 September 2013 13:09:00 Tom Wijsman wrote:
> Yes, I am aware of that, I am not saying it is unknown; but I am
> wondering about those questions: What kind of overhead does this cause?
At the first look I don't see anything wrong.

> Do you intend to discuss that flag or more generally any security flag?
both, let's talk the toolchain guys about.
-- 
Agostino Sarubbo
Gentoo Linux Developer

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

On Thu, 05 Sep 2013 12:13:28 +0200
Agostino Sarubbo <ago@gentoo.org> 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.
> 
> Note: please CC me in your response.

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

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]

On Thu, 5 Sep 2013 13:09:51 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Thu, 05 Sep 2013 12:13:28 +0200
> Agostino Sarubbo <ago@gentoo.org> 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.
> > 
> > Note: please CC me in your response.
> 
> Security does not come from the compiler. There is no compiler flag
> that magically makes insecure code secure.

That depends on how you define insecure code; if you define that as
excluding code which compiler flags can deal with, then I would agree.
But in general compiler flags like these can at least help.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Rich Freeman]

On Thu, Sep 5, 2013 at 7:09 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Thu, 05 Sep 2013 12:54:27 +0200
> Agostino Sarubbo <ago@gentoo.org> wrote:
>
>> On Thursday 05 September 2013 12:47:01 Tom Wijsman wrote:
>> > What I wonder about here is at which cost this does come, when
>> > looking at the fstack-protector then I see that it "emits extra
>> > code"; so, now the question is what kind of overhead this causes.
>>
>> We use -fstack-protector-all in the hardened profile, so it is not
>> unknown at all.
>>
>> > I am pretty sure security might not be that important on a real time
>> > system that perhaps isn't connected to the internet; so, besides
>> > making it the default, we might want to introduce the necessary
>> > means to turn it off again, by the very least perhaps documentation
>> > would suffice.
>> >
>> > Do you intend to discuss that flag or more generally any security
>> > flag?
>>
>> I just want to point out the thread because other people will have
>> something to say about.
>
> Yes, I am aware of that, I am not saying it is unknown; but I am
> wondering about those questions: What kind of overhead does this cause?
> Do you intend to discuss that flag or more generally any security flag?
>

I suspect that this it is minimal in most cases.  I used to use stack
protection for everything in the early days of amd64 and didn't have
performance issues when CPUs were considerably slower.  The bigger
issue was compatibility, which has likely improved.  I believe many
distros are using these flags more widely now, so the compatibility
issues may no longer exist.

Before any decision could be made we would at least need to assess the
compatibility issues for a broad number of packages.

Sure, we have hardened, but that is no reason to not consider enabling
the flag by default.  If the flag improves security and generally has
minimal downside then there really is no reason not to do so.
Hardened includes a lot of security improvements that come at a cost
of additional configuration, compatibility concerns, etc.

And to reduce the number of replies - I do realize that no compiler
option is a panacea whether we're talking about optimization or
security.  However, good security includes defense in depth, and stack
protection is an example of this.  Well-audited and designed code
still benefits from algorithmic protection since no review can be
certain to eliminate all security problems for a program of anything
more than trivial complexity.  I keep my system up-to-date and yet I
still run it behind a firewall.

Rich

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-----

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

[Parker Schmitt]

[-- Attachment #1: Type: text/plain, Size: 2143 bytes --]

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 <
zerochaos@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-----
>
>

[-- Attachment #2: Type: text/html, Size: 2860 bytes --]

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

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 2025 bytes --]

On Thu, 05 Sep 2013 12:13:28 +0200
Agostino Sarubbo <ago@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 Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Martin Vaeth]

Ryan Hill <dirtyepic@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.mccreesh@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
<vaeth@mathematik.uni-wuerzburg.de> wrote:
> Ryan Hill <dirtyepic@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
> <vaeth@mathematik.uni-wuerzburg.de> wrote:
> > Ryan Hill <dirtyepic@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 <ago@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 <pacho@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]

[-- Attachment #1: Type: text/plain, Size: 2834 bytes --]

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

> Ryan Hill <dirtyepic@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 Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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 +0000 (UTC)
> Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:
> 
>> Ryan Hill <dirtyepic@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

[Rich Freeman]

On Sat, Sep 7, 2013 at 7:08 PM, Rick "Zero_Chaos" Farina
<zerochaos@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

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

[Martin Vaeth]

Ryan Hill <dirtyepic@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 <dirtyepic@gentoo.org> wrote:
> Martin Vaeth <vaeth@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]

[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]

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
> <zerochaos@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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1807 bytes --]

On Sat, 07 Sep 2013 19:08:57 -0400
"Rick \"Zero_Chaos\" Farina" <zerochaos@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 Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 2005 bytes --]

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

> Ryan Hill <dirtyepic@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 Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Martin Vaeth]

Ryan Hill <dirtyepic@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 <dirtyepic@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]

[-- Attachment #1: Type: text/plain, Size: 2195 bytes --]

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

> On Sun, Sep 8, 2013 at 8:06 PM, Ryan Hill <dirtyepic@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 Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Peter Stuge]

[-- Attachment #1: Type: text/plain, Size: 352 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

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

[Jeroen Roovers]

On Sun, 8 Sep 2013 18:06:56 -0600
Ryan Hill <dirtyepic@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]

[-- Attachment #1: Type: text/plain, Size: 2474 bytes --]

On 09/08/2013 08:06 PM, Ryan Hill wrote:
> On Sat, 07 Sep 2013 19:08:57 -0400
> "Rick \"Zero_Chaos\" Farina" <zerochaos@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. ;)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

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

[Rich Freeman]

On Tue, Sep 10, 2013 at 6:41 PM, Richard Yao <ryao@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 <ryao@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]

[-- Attachment #1: Type: text/plain, Size: 1524 bytes --]

On Tue, 10 Sep 2013 18:41:34 -0400
Richard Yao <ryao@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 Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]

On Wed, 11 Sep 2013 04:49:55 +0000 (UTC)
Duncan <1i5t5.duncan@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 Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Magnus Granberg]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

onsdag 11 september 2013 00.07.29 skrev  Ryan Hill:
> On Tue, 10 Sep 2013 18:41:34 -0400
> 
> Richard Yao <ryao@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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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]

[-- Attachment #1: Type: text/plain, Size: 2434 bytes --]

måndag 09 september 2013 21.00.12 skrev  Ryan Hill:
> On Mon, 9 Sep 2013 08:21:35 -0400
> 
> Rich Freeman <rich0@gentoo.org> wrote:
> > On Sun, Sep 8, 2013 at 8:06 PM, Ryan Hill <dirtyepic@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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Richard Yao]

[-- Attachment #1: Type: text/plain, Size: 2978 bytes --]

On 09/10/2013 09:17 PM, Rich Freeman wrote:
> On Tue, Sep 10, 2013 at 6:41 PM, Richard Yao <ryao@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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

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

[Richard Yao]

[-- Attachment #1: Type: text/plain, Size: 1857 bytes --]

On 09/11/2013 02:07 AM, Ryan Hill wrote:
> On Tue, 10 Sep 2013 18:41:34 -0400
> Richard Yao <ryao@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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

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

[Richard Yao]

[-- Attachment #1: Type: text/plain, Size: 3317 bytes --]

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 <ryao@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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

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 +0000 (UTC)
> Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:
>
>> Ryan Hill <dirtyepic@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    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

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

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 660 bytes --]

On Thu, 12 Sep 2013 11:23:04 -0400
"Anthony G. Basile" <blueness@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 Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]