[gentoo-dev] Moving more hardening features to default?

[gentoo-dev] Moving more hardening features to default?

["Paweł Hajdan, Jr."]

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

Re: [gentoo-dev] Moving more hardening features to default?

[Anthony G. Basile]

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

Re: [gentoo-dev] Moving more hardening features to default?

[Tomáš Chvátal]

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

Re: [gentoo-dev] Moving more hardening features to default?

[Rich Freeman]

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

Re: [gentoo-dev] Moving more hardening features to default?

[Mike Frysinger]

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

Re: [gentoo-dev] Moving more hardening features to default?

[Anthony G. Basile]

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

Re: [gentoo-dev] Moving more hardening features to default?

[Rich Freeman]

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

Re: [gentoo-dev] Moving more hardening features to default?

[Mike Frysinger]

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

Re: [gentoo-dev] Moving more hardening features to default?

[Magnus Granberg]

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)

[gentoo-dev] Re: Moving more hardening features to default?

[Steven J Long]

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

Re: [gentoo-dev] Re: Moving more hardening features to default?

["Paweł Hajdan, Jr."]

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

Re: [gentoo-dev] Re: Moving more hardening features to default?

[Francisco Blas Izquierdo Riera (klondike)]

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

[gentoo-dev] Re: Re: Moving more hardening features to default?

[Steven J Long]

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

[gentoo-dev] Re: Moving more hardening features to default?

[Diego Elio Pettenò]

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

Re: [gentoo-dev] Re: Moving more hardening features to default?

[Mike Frysinger]

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

[gentoo-dev] Re: Moving more hardening features to default?

[Ryan Hill]

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

Re: [gentoo-dev] Moving more hardening features to default?

[Mike Frysinger]

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

[gentoo-dev] Re: Moving more hardening features to default?

[Duncan]

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

Re: [gentoo-dev] Re: Moving more hardening features to default?

[Mike Frysinger]

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

[gentoo-dev] Re: Moving more hardening features to default?

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

Re: [gentoo-dev] Re: Moving more hardening features to default?

[Magnus Granberg]

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

Re: [gentoo-dev] Moving more hardening features to default?

[Kacper Kowalik]

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

Re: [gentoo-dev] Moving more hardening features to default?

[Patrick Lauer]

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)

Re: [gentoo-dev] Moving more hardening features to default?

[Rich Freeman]

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

Re: [gentoo-dev] Moving more hardening features to default?

["Paweł Hajdan, Jr."]

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