* [gentoo-dev] Moving more hardening features to default?
@ 2011-10-20 8:47 "Paweł Hajdan, Jr."
2011-10-20 10:40 ` Anthony G. Basile
` (2 more replies)
0 siblings, 3 replies; 25+ messages in thread
From: "Paweł Hajdan, Jr." @ 2011-10-20 8:47 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 473 bytes --]
I've noticed
<http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags>, i.e.
Debian is starting to make more and more hardening features default, at
least for most packages.
Should we start doing that too? What are possible problems with that? It
seems like it's mostly about USE=hardened, right?
I've noticed that several binary drivers like nvidia-drivers are masked
on hardened - is it a problem with hardened-sources, or with hardened
toolchain?
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Moving more hardening features to default?
2011-10-20 8:47 [gentoo-dev] Moving more hardening features to default? "Paweł Hajdan, Jr."
@ 2011-10-20 10:40 ` Anthony G. Basile
2011-10-20 10:46 ` Tomáš Chvátal
` (2 more replies)
2011-10-20 12:55 ` [gentoo-dev] " Mike Frysinger
2011-10-25 14:18 ` [gentoo-dev] " Kacper Kowalik
2 siblings, 3 replies; 25+ messages in thread
From: Anthony G. Basile @ 2011-10-20 10:40 UTC (permalink / raw
To: gentoo-dev
On 10/20/2011 04:47 AM, "Paweł Hajdan, Jr." wrote:
> I've noticed
> <http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags>, i.e.
> Debian is starting to make more and more hardening features default, at
> least for most packages.
>
> Should we start doing that too? What are possible problems with that? It
> seems like it's mostly about USE=hardened, right?
>
> I've noticed that several binary drivers like nvidia-drivers are masked
> on hardened - is it a problem with hardened-sources, or with hardened
> toolchain?
>
The nvidia-driver problem is due to PaX in the kernel, so its
hardened-sources.
USE=hardened refers to only toolchain hardening. The problems there are
mostly packages which break with PIE because they (ab)use assembly.
Things like virtualbox and some codecs. This can become a thorny mess.
It would probably be nearly painless to bring in -D_FORTIFY_SOURCES=2
and ssp into mainstream though. Packages which break because of either
of those two features are broken and should be fixed anyhow.
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535
GnuPG ID : D0455535
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Moving more hardening features to default?
2011-10-20 10:40 ` Anthony G. Basile
@ 2011-10-20 10:46 ` Tomáš Chvátal
2011-10-20 12:41 ` Rich Freeman
2011-10-20 11:46 ` [gentoo-dev] " Diego Elio Pettenò
2011-10-21 5:39 ` Ryan Hill
2 siblings, 1 reply; 25+ messages in thread
From: Tomáš Chvátal @ 2011-10-20 10:46 UTC (permalink / raw
To: gentoo-dev
2011/10/20 Anthony G. Basile <blueness@gentoo.org>:
> USE=hardened refers to only toolchain hardening. The problems there are
> mostly packages which break with PIE because they (ab)use assembly.
> Things like virtualbox and some codecs. This can become a thorny mess.
>
> It would probably be nearly painless to bring in -D_FORTIFY_SOURCES=2
> and ssp into mainstream though. Packages which break because of either
> of those two features are broken and should be fixed anyhow.
>
This sounds like good idea to do so,
I would say that most hardened features should be merged to to main
profile as soon as they won't cause major PITA for the regular users.
Cheers
Tom
^ permalink raw reply [flat|nested] 25+ messages in thread
* [gentoo-dev] Re: Moving more hardening features to default?
2011-10-20 10:40 ` Anthony G. Basile
2011-10-20 10:46 ` Tomáš Chvátal
@ 2011-10-20 11:46 ` Diego Elio Pettenò
2011-10-20 12:49 ` Mike Frysinger
2011-10-21 5:39 ` Ryan Hill
2 siblings, 1 reply; 25+ messages in thread
From: Diego Elio Pettenò @ 2011-10-20 11:46 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 464 bytes --]
Il giorno gio, 20/10/2011 alle 06.40 -0400, Anthony G. Basile ha
scritto:
> It would probably be nearly painless to bring in -D_FORTIFY_SOURCES=2
> and ssp into mainstream though. Packages which break because of
> either
> of those two features are broken and should be fixed anyhow.
-D_FORTIFY_SOURCES=2 has been enabled in mainline since GCC 4.3.3-r1 if
my memory serves me right.
--
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Moving more hardening features to default?
2011-10-20 10:46 ` Tomáš Chvátal
@ 2011-10-20 12:41 ` Rich Freeman
2011-10-20 12:57 ` Mike Frysinger
0 siblings, 1 reply; 25+ messages in thread
From: Rich Freeman @ 2011-10-20 12:41 UTC (permalink / raw
To: gentoo-dev
2011/10/20 Tomáš Chvátal <scarabeus@gentoo.org>:
> I would say that most hardened features should be merged to to main
> profile as soon as they won't cause major PITA for the regular users.
I agree - especially for stuff that doesn't require active setup
(stack protection, PaX, etc).
If there are features that we could turn on but for a few packages,
maybe the solution there is to discuss them on-list and target them
for future adoption and make an effort to fix the impacted ebuilds.
Fix could mean either making the package work with the hardened
feature, or disabling it just for that package (filter-flags, tag
binaries not to run with features, etc).
The hardened profile can still of course be the place where we push
the envelope at the cost of more packages being masked, and there will
always be things like MAC that represent a big change in how a system
is run that will take a long time to become mainstream.
Rich
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Re: Moving more hardening features to default?
2011-10-20 11:46 ` [gentoo-dev] " Diego Elio Pettenò
@ 2011-10-20 12:49 ` Mike Frysinger
0 siblings, 0 replies; 25+ messages in thread
From: Mike Frysinger @ 2011-10-20 12:49 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: Text/Plain, Size: 594 bytes --]
On Thursday 20 October 2011 07:46:57 Diego Elio Pettenò wrote:
> Il giorno gio, 20/10/2011 alle 06.40 -0400, Anthony G. Basile ha scritto:
> > It would probably be nearly painless to bring in -D_FORTIFY_SOURCES=2
> > and ssp into mainstream though. Packages which break because of
> > either
> > of those two features are broken and should be fixed anyhow.
>
> -D_FORTIFY_SOURCES=2 has been enabled in mainline since GCC 4.3.3-r1 if
> my memory serves me right.
it isn't in mainline gcc. but it is in all Gentoo gcc versions since 4.3.3.
first added like 3 years ago.
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Moving more hardening features to default?
2011-10-20 8:47 [gentoo-dev] Moving more hardening features to default? "Paweł Hajdan, Jr."
2011-10-20 10:40 ` Anthony G. Basile
@ 2011-10-20 12:55 ` Mike Frysinger
2011-10-21 3:20 ` [gentoo-dev] " Duncan
2011-10-25 14:18 ` [gentoo-dev] " Kacper Kowalik
2 siblings, 1 reply; 25+ messages in thread
From: Mike Frysinger @ 2011-10-20 12:55 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: Text/Plain, Size: 765 bytes --]
On Thursday 20 October 2011 04:47:14 Paweł Hajdan, Jr. wrote:
> I've noticed
> <http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags>, i.e.
> Debian is starting to make more and more hardening features default, at
> least for most packages.
seems a bit light on what actually is being used
random thoughts:
- we've long defaulted to linking with relro
- defaulting to bindnow is pretty much a no go for USE=-hardened
- building everything as PIC/PIE comes with performance penalty for some
architectures (e.g. x86), and is often the source of build issues with the
hardened port
- we've long defaulted to building with _FORTIFY_SOURCE
- i'd need to see actual overhead data with SSP to see about enabling it by
default
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Moving more hardening features to default?
2011-10-20 12:41 ` Rich Freeman
@ 2011-10-20 12:57 ` Mike Frysinger
2011-10-20 14:36 ` Anthony G. Basile
0 siblings, 1 reply; 25+ messages in thread
From: Mike Frysinger @ 2011-10-20 12:57 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: Text/Plain, Size: 448 bytes --]
On Thursday 20 October 2011 08:41:55 Rich Freeman wrote:
> 2011/10/20 Tomáš Chvátal:
> > I would say that most hardened features should be merged to to main
> > profile as soon as they won't cause major PITA for the regular users.
>
> I agree - especially for stuff that doesn't require active setup
> (stack protection, PaX, etc).
except PaX requires kernel patches and is known to break things. not an
acceptable default.
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Moving more hardening features to default?
2011-10-20 12:57 ` Mike Frysinger
@ 2011-10-20 14:36 ` Anthony G. Basile
2011-10-20 16:47 ` Rich Freeman
0 siblings, 1 reply; 25+ messages in thread
From: Anthony G. Basile @ 2011-10-20 14:36 UTC (permalink / raw
To: gentoo-dev
On 10/20/2011 08:57 AM, Mike Frysinger wrote:
> On Thursday 20 October 2011 08:41:55 Rich Freeman wrote:
>> 2011/10/20 Tomáš Chvátal:
>>> I would say that most hardened features should be merged to to main
>>> profile as soon as they won't cause major PITA for the regular users.
>> I agree - especially for stuff that doesn't require active setup
>> (stack protection, PaX, etc).
> except PaX requires kernel patches and is known to break things. not an
> acceptable default.
> -mike
I would not recommend PaX at this time. As Mike said, it breaks things,
sometimes important things. Eg. python ctypes was broken there for a
while on hardened. Also, unlike toolchain, it requires that you
configure your kernel correctly, ie have familiarity with what works and
what doesn't under certain PaX features. This may be trivial for us,
but might be more than we want to put newbies through.
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535
GnuPG ID : D0455535
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Moving more hardening features to default?
2011-10-20 14:36 ` Anthony G. Basile
@ 2011-10-20 16:47 ` Rich Freeman
2011-10-20 17:17 ` Mike Frysinger
0 siblings, 1 reply; 25+ messages in thread
From: Rich Freeman @ 2011-10-20 16:47 UTC (permalink / raw
To: gentoo-dev
On Thu, Oct 20, 2011 at 10:36 AM, Anthony G. Basile <blueness@gentoo.org> wrote:
> I would not recommend PaX at this time. As Mike said, it breaks things,
> sometimes important things. Eg. python ctypes was broken there for a
> while on hardened. Also, unlike toolchain, it requires that you
> configure your kernel correctly, ie have familiarity with what works and
> what doesn't under certain PaX features. This may be trivial for us,
> but might be more than we want to put newbies through.
I used it as an example because it is passive for the most part, and I
think most of the configuration could be handled by the ebuilds.
However, I didn't mean to suggest that it was ready to be made a
default. If the list of broken packages were small enough I think
that it would be fair to consider it as a future default to work
towards.
I was trying to draw a contrast between passive things like
stack-protection and things that really get in your face like MAC.
Rich
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Moving more hardening features to default?
2011-10-20 16:47 ` Rich Freeman
@ 2011-10-20 17:17 ` Mike Frysinger
2011-10-20 20:51 ` Magnus Granberg
0 siblings, 1 reply; 25+ messages in thread
From: Mike Frysinger @ 2011-10-20 17:17 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: Text/Plain, Size: 634 bytes --]
On Thursday 20 October 2011 12:47:27 Rich Freeman wrote:
> I was trying to draw a contrast between passive things like
> stack-protection and things that really get in your face like MAC.
the trouble was in the context quoting then ... it sounded like you were
proposing PaX by default
i am a fan of things that "just work" though which is why i was happy to merge
the fortify source code. most of that checking is done at compile time, so
the runtime overhead is generally small. and in terms of packages that did
break, it was (more often than not) because they were broken already but we
never noticed.
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Moving more hardening features to default?
2011-10-20 17:17 ` Mike Frysinger
@ 2011-10-20 20:51 ` Magnus Granberg
2011-10-23 3:56 ` [gentoo-dev] " Steven J Long
0 siblings, 1 reply; 25+ messages in thread
From: Magnus Granberg @ 2011-10-20 20:51 UTC (permalink / raw
To: gentoo-dev
torsdag 20 oktober 2011 13.17.33 skrev Mike Frysinger:
> On Thursday 20 October 2011 12:47:27 Rich Freeman wrote:
> > I was trying to draw a contrast between passive things like
> > stack-protection and things that really get in your face like MAC.
>
> the trouble was in the context quoting then ... it sounded like you were
> proposing PaX by default
>
> i am a fan of things that "just work" though which is why i was happy to
> merge the fortify source code. most of that checking is done at compile
> time, so the runtime overhead is generally small. and in terms of packages
> that did break, it was (more often than not) because they were broken
> already but we never noticed.
> -mike
Hi
Debian has start to add some hardened features but take a look at ubuntu
https://wiki.ubuntu.com/Security/Features
Adding ssp support to main would not be a problem for most package works with
it. We use same patch as ubuntu's toolchain to enable ssp, but we enable
-fstack-protector-all instead of -fstack-protector. You will, however, have
some performance penalty enabling it.
Adding PIE to main is much harder than ssp. On x86 it will have a high
performance penalty and a lot of trouble with asm code. The only arch I would
add PIE on is amd64 where it will have only a minor performance penalty and we
already have shared libs compile with PIC. The biggest problem we have with
PIE on amd64 is asm code in the apps where upstream is not that interested in
making the asm PIC aware. It hards to keep the patches up to date when they
are not maintained upstream.
There are about 30 packages which have problems with PIE. We either add patch
to these or else use filter-flags on them.
my 2c
/Magnus (Zorry)
^ permalink raw reply [flat|nested] 25+ messages in thread
* [gentoo-dev] Re: Moving more hardening features to default?
2011-10-20 12:55 ` [gentoo-dev] " Mike Frysinger
@ 2011-10-21 3:20 ` Duncan
2011-10-21 12:13 ` Mike Frysinger
0 siblings, 1 reply; 25+ messages in thread
From: Duncan @ 2011-10-21 3:20 UTC (permalink / raw
To: gentoo-dev
Mike Frysinger posted on Thu, 20 Oct 2011 08:55:35 -0400 as excerpted:
> On Thursday 20 October 2011 04:47:14 Paweł Hajdan, Jr. wrote:
>> <http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags>
>> Debian is starting to make more and more hardening features default
> random thoughts:
> - we've long defaulted to linking with relro
> - defaulting to bindnow is pretty much a no go for USE=-hardened
> - PIC/PIE comes with performance penalty for (e.g. x86),
> and is often the source of build issues with the hardened port
> - we've long defaulted to building with _FORTIFY_SOURCE
Thanks on relro and fortify_source.
Magnus G suggests possibly adding PIE to amd64, which is already PIC,
with the big issue there being the packages doing assembly where the
upstreams aren't interested in PIC compliance so Gentoo has to maintain
the patches. He says ~30 packages. Obviously hardened already has quite
some experience here, and making PIE the amd64 default would certainly
broaden the base and should thus make it easier than just hardened caring
now, but at a bit more trouble for mainline ~amd64, I'd imagine.
Still, speaking as an ~amd64 user myself, that's certainly an acceptable
tradeoff from the user-side, particularly as most users will only have
perhaps a handful of those 30 packages installed. If the gentoo/amd64
folks and the maintainers of those 30 packages don't mind too much, I
believe it does make sense.
Then, as legacy x86 gradually dies off and those who haven't already done
so gradually switch to amd64 (or possibly arm, but I don't know enough
about that to comment in this context), they'd get the security upgrade
as a part of the package. =:^)
What about x32, tho? Does it get PIC by default too, or not, and if not,
given that it's a new arch, would enabling both PIC and PIE and taking
whatever hit it brings with it be acceptable? What /are/ the costs
there, more like x86 or amd64?
And for bindnow, do you mean the "-Wl,-z,now" that's part of my LDFLAGS?
If so, I've been running it for years on amd64 at least, no hardened
here. And for less time but similarly system-wide, I'm running it on my
early 32-bit-atom-based netbook (acer aspire one, AOA150L). AFAIK
there's some initial-load-time and arguably some memory cost, but less
post-load run-time latency and issues when those libs would be otherwise
be lazy-loaded, and I decided that tradeoff was one I could live with!
=:^)
Years ago there were some issues with the xf86-video-ati driver due to
circular load-time dependency issues so I had to disable it for that
package (and possibly for a couple other X-related packages) for awhile,
but any remaining issues in the packages I run, at least, have been long
dealt with in the ebuilds using stripflags or whatever, and I've not had
any LDFLAG changes in my /etc/portage/env/*/* files for quite some time.
So while Frysinger's certainly the expert that I'm not, and assuming
we're talking about the same thing, at least on my kde-based systems both
amd64 and x86, my bindnow experience has actually been remarkably
smooth, /way/ more so than say... CFLAGS containing -combine (as mine
do), for which I've rather a number of /etc/portage/env/*/* entries.
So from my experience, bindnow would be a go as well. But I've always
been interested in why it might not be the default I thought it seemed it
should be, so if Mike or anyone else can point me at something suggesting
other than initial-load latency and quite rare circular load issues (or
for that matter, much else on that flag, since I frankly don't know as
much about it as I'd like), I'd love to read up!
--
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* [gentoo-dev] Re: Moving more hardening features to default?
2011-10-20 10:40 ` Anthony G. Basile
2011-10-20 10:46 ` Tomáš Chvátal
2011-10-20 11:46 ` [gentoo-dev] " Diego Elio Pettenò
@ 2011-10-21 5:39 ` Ryan Hill
2 siblings, 0 replies; 25+ messages in thread
From: Ryan Hill @ 2011-10-21 5:39 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]
On Thu, 20 Oct 2011 06:40:43 -0400
"Anthony G. Basile" <blueness@gentoo.org> wrote:
> USE=hardened refers to only toolchain hardening. The problems there are
> mostly packages which break with PIE because they (ab)use assembly.
> Things like virtualbox and some codecs. This can become a thorny mess.
>
> It would probably be nearly painless to bring in -D_FORTIFY_SOURCES=2
> and ssp into mainstream though. Packages which break because of either
> of those two features are broken and should be fixed anyhow.
If any of these features (other than -D_FORTIFY_SOURCE) relies on spec rule
handling of preprocessor flags then I'd like you to try reimplementing them
another way. I'm going to hack 4.6 to work properly but I expect it to break
again with 4.7.
--
fonts, gcc-porting, it makes no sense how it makes no sense
toolchain, wxwidgets but i'll take it free anytime
@ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Re: Moving more hardening features to default?
2011-10-21 3:20 ` [gentoo-dev] " Duncan
@ 2011-10-21 12:13 ` Mike Frysinger
2011-10-21 15:25 ` Duncan
0 siblings, 1 reply; 25+ messages in thread
From: Mike Frysinger @ 2011-10-21 12:13 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: Text/Plain, Size: 1669 bytes --]
On Thursday 20 October 2011 23:20:35 Duncan wrote:
> Magnus G suggests possibly adding PIE to amd64, which is already PIC,
this isn't quite right. amd64 shared objects (i.e. libraries) are PIC. the
applications are not.
> Still, speaking as an ~amd64 user myself, that's certainly an acceptable
> tradeoff from the user-side, particularly as most users will only have
> perhaps a handful of those 30 packages installed. If the gentoo/amd64
> folks and the maintainers of those 30 packages don't mind too much, I
> believe it does make sense.
usually these packages are multimedia related. like ffmpeg iirc. so i think
the impact is much greater than your estimate here.
> Then, as legacy x86 gradually dies off and those who haven't already done
> so gradually switch to amd64 (or possibly arm, but I don't know enough
> about that to comment in this context), they'd get the security upgrade
> as a part of the package. =:^)
poor PIC performance isn't specific to x86. it's just the largest affected user
base. i'd have to dig into the ABI's to say which others have issues.
> What about x32, tho? Does it get PIC by default too, or not, and if not,
x32 is same as x86_64 wrt PIC
> And for bindnow, do you mean the "-Wl,-z,now" that's part of my LDFLAGS?
yes
> there's some initial-load-time and arguably some memory cost, but less
> post-load run-time latency and issues when those libs would be otherwise
> be lazy-loaded, and I decided that tradeoff was one I could live with!
i don't think there's a memory cost. the initial load time is waste and is
noticeable on much larger packages like OOo.
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* [gentoo-dev] Re: Moving more hardening features to default?
2011-10-21 12:13 ` Mike Frysinger
@ 2011-10-21 15:25 ` Duncan
2011-10-21 16:37 ` Magnus Granberg
0 siblings, 1 reply; 25+ messages in thread
From: Duncan @ 2011-10-21 15:25 UTC (permalink / raw
To: gentoo-dev
Mike Frysinger posted on Fri, 21 Oct 2011 08:13:22 -0400 as excerpted:
> On Thursday 20 October 2011 23:20:35 Duncan wrote:
>> Magnus G suggests possibly adding PIE to amd64, which is already PIC,
>
> this isn't quite right. amd64 shared objects (i.e. libraries) are PIC.
> the applications are not.
Thanks for the correction. I knew the library think but supposed that
was the difference between PIC/PIE, the E/executable for executables
only, the more generic C/code for the feature applied to shared objects.
Seems there's a bit more to it than that. Thanks again, I can look it up
now that I know to do so.
> usually these packages are multimedia related. like ffmpeg iirc. so i
> think the impact is much greater than your estimate here.
I figured mm, but also assumed strip-flags-like exceptions (probably
controlled via USE flag) for packages where the default was really
costly. But now that I think of it, implementing that as arch defaults
while allowing overrides isn't quite the simple matter it is for user-set
CFLAGS, etc, and strip-flags, etc.
I assume it can still be done, but am not in a position to estimate
whether it'd be worth the cost to implement.
>> What about x32, tho? Does it get PIC by default too
>
> x32 is same as x86_64 wrt PIC
Good to know. Thanks.
--
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Re: Moving more hardening features to default?
2011-10-21 15:25 ` Duncan
@ 2011-10-21 16:37 ` Magnus Granberg
0 siblings, 0 replies; 25+ messages in thread
From: Magnus Granberg @ 2011-10-21 16:37 UTC (permalink / raw
To: gentoo-dev
fredag 21 oktober 2011 15.25.54 skrev Duncan:
> Mike Frysinger posted on Fri, 21 Oct 2011 08:13:22 -0400 as excerpted:
> > On Thursday 20 October 2011 23:20:35 Duncan wrote:
> >> Magnus G suggests possibly adding PIE to amd64, which is already PIC,
> >
> > this isn't quite right. amd64 shared objects (i.e. libraries) are PIC.
> > the applications are not.
>
> Thanks for the correction. I knew the library think but supposed that
> was the difference between PIC/PIE, the E/executable for executables
> only, the more generic C/code for the feature applied to shared objects.
>
> Seems there's a bit more to it than that. Thanks again, I can look it up
> now that I know to do so.
>
> > usually these packages are multimedia related. like ffmpeg iirc. so i
> > think the impact is much greater than your estimate here.
>
I don't have any probs with ffmpeg. We disable the asm stuff only for x86 and
not amd64 and that is the case on alot of the multimedia related packages.
Most problem we have now is the packages in app-emulation
> I figured mm, but also assumed strip-flags-like exceptions (probably
> controlled via USE flag) for packages where the default was really
> costly. But now that I think of it, implementing that as arch defaults
> while allowing overrides isn't quite the simple matter it is for user-set
> CFLAGS, etc, and strip-flags, etc.
We allready use pic USE flag, filter-flags -fPIE or gcc-specs-pie to disable
or do stuff so the package works.
>
> I assume it can still be done, but am not in a position to estimate
> whether it'd be worth the cost to implement.
>
> >> What about x32, tho? Does it get PIC by default too
> >
> > x32 is same as x86_64 wrt PIC
>
> Good to know. Thanks.
/Magnus
^ permalink raw reply [flat|nested] 25+ messages in thread
* [gentoo-dev] Re: Moving more hardening features to default?
2011-10-20 20:51 ` Magnus Granberg
@ 2011-10-23 3:56 ` Steven J Long
2011-10-25 10:10 ` "Paweł Hajdan, Jr."
2011-10-25 16:12 ` Francisco Blas Izquierdo Riera (klondike)
0 siblings, 2 replies; 25+ messages in thread
From: Steven J Long @ 2011-10-23 3:56 UTC (permalink / raw
To: gentoo-dev
Magnus Granberg wrote:
> It's hard to keep the patches up to date when they
> are not maintained upstream.
>
> There are about 30 packages which have problems with PIE. We either add
> patch to these or else use filter-flags on them.
Sounds perfectly reasonable just to filter those, and not give yourself the
maintenance burden.
Will we be able to switch off SSP via config, or will we have to setup our
own profile?
(Since PIE has minimal performance burden on AMD64, and won't be default
elsewhere it doesn't seem like a concern.)
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Re: Moving more hardening features to default?
2011-10-23 3:56 ` [gentoo-dev] " Steven J Long
@ 2011-10-25 10:10 ` "Paweł Hajdan, Jr."
2011-10-25 16:12 ` Francisco Blas Izquierdo Riera (klondike)
1 sibling, 0 replies; 25+ messages in thread
From: "Paweł Hajdan, Jr." @ 2011-10-25 10:10 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 327 bytes --]
On 10/23/11 5:56 AM, Steven J Long wrote:
> Will we be able to switch off SSP via config, or will we have to setup our
> own profile?
In my proposal the SSP would be off by default on non-hardened profiles,
at least initially. At any time I'd like it to be switchable via
gcc-config, as it currently is on hardened.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Moving more hardening features to default?
2011-10-20 8:47 [gentoo-dev] Moving more hardening features to default? "Paweł Hajdan, Jr."
2011-10-20 10:40 ` Anthony G. Basile
2011-10-20 12:55 ` [gentoo-dev] " Mike Frysinger
@ 2011-10-25 14:18 ` Kacper Kowalik
2011-10-25 14:46 ` Patrick Lauer
2011-10-25 15:11 ` Rich Freeman
2 siblings, 2 replies; 25+ messages in thread
From: Kacper Kowalik @ 2011-10-25 14:18 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 780 bytes --]
W dniu 20.10.2011 10:47, "Paweł Hajdan, Jr." pisze:
> I've noticed
> <http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags>, i.e.
> Debian is starting to make more and more hardening features default, at
> least for most packages.
>
> Should we start doing that too? What are possible problems with that? It
> seems like it's mostly about USE=hardened, right?
Hi,
just a bunch of quick questions from a hardened newbie:
1) Is there are reason to do it beside "Debian is going to do it"?
2) What's wrong with current approach i.e. having seperate hardened profile?
3) What are the benefits for an average desktop user or high-performance
cluster?
While answering that, please skip things obvious like having "more
secure box".
Cheers,
Kacper
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Moving more hardening features to default?
2011-10-25 14:18 ` [gentoo-dev] " Kacper Kowalik
@ 2011-10-25 14:46 ` Patrick Lauer
2011-10-25 15:11 ` Rich Freeman
1 sibling, 0 replies; 25+ messages in thread
From: Patrick Lauer @ 2011-10-25 14:46 UTC (permalink / raw
To: gentoo-dev
On 10/25/11 16:18, Kacper Kowalik wrote:
> W dniu 20.10.2011 10:47, "Paweł Hajdan, Jr." pisze:
>> I've noticed
>> <http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags>, i.e.
>> Debian is starting to make more and more hardening features default, at
>> least for most packages.
>>
>> Should we start doing that too? What are possible problems with that? It
>> seems like it's mostly about USE=hardened, right?
> Hi,
> just a bunch of quick questions from a hardened newbie:
>
> 1) Is there are reason to do it beside "Debian is going to do it"?
For most users it has no negative impact. So in terms of cost it is,
analogous to as-needed, a little bit more work for us as maintainers. On
the upside we get the "more secure" thing you don't care about.
And you can still turn it all off, so you have no mandatory changes
(except configuration defaults)
> 2) What's wrong with current approach i.e. having seperate hardened profile?
Nothing wrong per se, but it would be beneficial to make these paranoia
features more available to users. You can still turn 'em all off, if you
want, so we're basically only suggesting to go from an opt-in to an
opt-out for those features.
> 3) What are the benefits for an average desktop user or high-performance
> cluster?
>
> While answering that, please skip things obvious like having "more
> secure box".
From that perspective none, but for those of us that do other things
(like running public-facing servers) it lets us sleep a bit better at night.
Counter-question would be what's the downside - I've seen no benchmarks
that show a serious performance impact for most features (last time I
looked most of the PaX kernel features are <1% runtime cost)
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Moving more hardening features to default?
2011-10-25 14:18 ` [gentoo-dev] " Kacper Kowalik
2011-10-25 14:46 ` Patrick Lauer
@ 2011-10-25 15:11 ` Rich Freeman
2011-10-25 15:38 ` "Paweł Hajdan, Jr."
1 sibling, 1 reply; 25+ messages in thread
From: Rich Freeman @ 2011-10-25 15:11 UTC (permalink / raw
To: gentoo-dev
On Tue, Oct 25, 2011 at 10:18 AM, Kacper Kowalik <xarthisius@gentoo.org> wrote:
> 2) What's wrong with current approach i.e. having seperate hardened profile?
I don't really see the hardened profile and some hardening by default
as being redundant.
When I think about the hardened profile I think high security at the
cost of software compatibility. If you're running a virtual
webhosting company you probably don't care that mplayer doesn't work
on your virtual hosts but you do care that some zero-day exploit could
let somebody escape from their sandbox.
The default configuration should aim for a reasonable balance of
security and convenience. We still fix or mask known security issues,
and we still do stuff like not shipping lots of stuff listening on
ports by default.
If adding something to CFLAGS makes systems more secure with minimal
compatibility or performance problems, then there is no reason not to
do it.
And "Debian is doing it" or whatever isn't actually a bad reason to
consider this. When Debian does something by default, it means that
upstream packages will take notice. In fact, you could even see
something that today would be strange like having upstream mark a bug
report invalid because you DIDN'T have stack protection enabled or
whatever. Doing things that are dumb just because others are doing it
isn't a good thing, but just being different for the sake of being
different isn't either.
Rich
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Moving more hardening features to default?
2011-10-25 15:11 ` Rich Freeman
@ 2011-10-25 15:38 ` "Paweł Hajdan, Jr."
0 siblings, 0 replies; 25+ messages in thread
From: "Paweł Hajdan, Jr." @ 2011-10-25 15:38 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]
On 10/25/11 5:11 PM, Rich Freeman wrote:
> And "Debian is doing it" or whatever isn't actually a bad reason to
> consider this. When Debian does something by default, it means that
> upstream packages will take notice.
Right, I was thinking about the change for a long time, but if Debian,
which advertises itself as stable and well-tested, thinks it's time to
do it, then why should we stay behind?
My primary motivation is doing the right thing, and linking to Debian's
plans is one of my points to show that it makes sense.
I think that generally just trying to patch detected vulnerabilities as
soon as possible is not sufficient to stay reasonably secure. Mitigation
techniques like SSP and ASLR are really important, because they give you
more time to fix vulnerabilities (by making it harder to exploit them).
And again, I don't suggest enabling anything by default that would
degrade performance in an unacceptable way or create compatibility
problems that can't be solved. And I'm also looking for a way that will
provide a seamless upgrade path for existing users (i.e. one that
doesn't break them).
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Re: Moving more hardening features to default?
2011-10-23 3:56 ` [gentoo-dev] " Steven J Long
2011-10-25 10:10 ` "Paweł Hajdan, Jr."
@ 2011-10-25 16:12 ` Francisco Blas Izquierdo Riera (klondike)
2011-10-27 1:13 ` [gentoo-dev] " Steven J Long
1 sibling, 1 reply; 25+ messages in thread
From: Francisco Blas Izquierdo Riera (klondike) @ 2011-10-25 16:12 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 205 bytes --]
El 23/10/11 05:56, Steven J Long escribió:
> Will we be able to switch off SSP via config, or will we have to setup our
> own profile?
This should do the trick:
CFLAGS=$CFLAGS -fno-stack-protector
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* [gentoo-dev] Re: Re: Moving more hardening features to default?
2011-10-25 16:12 ` Francisco Blas Izquierdo Riera (klondike)
@ 2011-10-27 1:13 ` Steven J Long
0 siblings, 0 replies; 25+ messages in thread
From: Steven J Long @ 2011-10-27 1:13 UTC (permalink / raw
To: gentoo-dev
Francisco Blas Izquierdo Riera (klondike) wrote:
> El 23/10/11 05:56, Steven J Long escribió:
>> Will we be able to switch off SSP via config, or will we have to setup
>> our own profile?
> This should do the trick:
> CFLAGS=$CFLAGS -fno-stack-protector
Well, with quotes ;) but yeah that's what I was after; just something I
can add somewhere in make.conf.
Paweł Hajdan, Jr. wrote:
> In my proposal the SSP would be off by default on non-hardened profiles,
> at least initially. At any time I'd like it to be switchable via
> gcc-config, as it currently is on hardened.
That sounds good too; I'll use the default and then add -fstack-protector
to package.env should I ever want to compile a package like that. (In case
it sounds like I don't care about security, it's just that I don't like
stack canaries, and feel address-space randomization via -fPIE will make
the classic return-address subversion pretty difficult. Of course I might
be missing something again, but I'm not administering a server.)
Thanks for your replies, and all the hard work you do.
Regards,
igli.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2011-10-27 1:10 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-10-20 8:47 [gentoo-dev] Moving more hardening features to default? "Paweł Hajdan, Jr."
2011-10-20 10:40 ` Anthony G. Basile
2011-10-20 10:46 ` Tomáš Chvátal
2011-10-20 12:41 ` Rich Freeman
2011-10-20 12:57 ` Mike Frysinger
2011-10-20 14:36 ` Anthony G. Basile
2011-10-20 16:47 ` Rich Freeman
2011-10-20 17:17 ` Mike Frysinger
2011-10-20 20:51 ` Magnus Granberg
2011-10-23 3:56 ` [gentoo-dev] " Steven J Long
2011-10-25 10:10 ` "Paweł Hajdan, Jr."
2011-10-25 16:12 ` Francisco Blas Izquierdo Riera (klondike)
2011-10-27 1:13 ` [gentoo-dev] " Steven J Long
2011-10-20 11:46 ` [gentoo-dev] " Diego Elio Pettenò
2011-10-20 12:49 ` Mike Frysinger
2011-10-21 5:39 ` Ryan Hill
2011-10-20 12:55 ` [gentoo-dev] " Mike Frysinger
2011-10-21 3:20 ` [gentoo-dev] " Duncan
2011-10-21 12:13 ` Mike Frysinger
2011-10-21 15:25 ` Duncan
2011-10-21 16:37 ` Magnus Granberg
2011-10-25 14:18 ` [gentoo-dev] " Kacper Kowalik
2011-10-25 14:46 ` Patrick Lauer
2011-10-25 15:11 ` Rich Freeman
2011-10-25 15:38 ` "Paweł Hajdan, Jr."
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox