Re: [gentoo-dev] Re: Improve the security of the default profile
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: git-r3: initial draft for review [v2]
Walter Dnes waltd...@waltdnes.org wrote: Note that... grep foo bar.txt ...returns colour-highlighted text, while... grep foo bar.txt output.txt ...returns plain text. So it can be done properly for everybody. No, it cannot be done properly for everybody: grep foo bar.txt | tee output.txt Unfortunately, this corresponds exactly to portage's setup: Commands like einfo would have to produce different output on different channels which they cannot do if portage redirects/copies globally. Portage would need a rather cumbersome (and presumably slow) catching of such output for each command separately. Filtering the logfiles afterwards is probably simpler.
[gentoo-dev] Lastrites: net-irc/ezbounce, app-misc/gpsdrive, sys-fs/cdfs, =dev-cpp/libxmlpp-1.0*, app-arch/xarchiver
# Pacho Ramos pa...@gentoo.org (07 Sep 2013) # Fails to build with gcc-4.7, no release since 2009, # nothing in the tree needs it. Removal in a month. net-irc/ezbounce # Pacho Ramos pa...@gentoo.org (07 Sep 2013) # Upstream looks dead, lots of unattended bugs needing # patches (#369007, #444135, #446424, #458856). # Removal in a month. app-misc/gpsdrive # Pacho Ramos pa...@gentoo.org (07 Sep 2013) # Upstream dead, incompatible with current kernels # (#460138). Removal in a month. sys-fs/cdfs # Pacho Ramos pa...@gentoo.org (07 Sep 2013) # Obsolete for ages, nothing needs it (#482904). # Removal in a month. =dev-cpp/libxmlpp-1.0* # Pacho Ramos pa...@gentoo.org (07 Sep 2013) # Incompatible with latest rar (#483588), abandoned # for years. Removal in a month. app-arch/xarchiver
[gentoo-dev] Re: Improve the security of the default profile
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
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
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
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
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
-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
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
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
-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-
