* hardening
@ 2018-01-29 12:44 ng0
2018-01-29 19:21 ` hardening Joshua Branson
2018-01-31 12:20 ` hardening Alex Vong
0 siblings, 2 replies; 22+ messages in thread
From: ng0 @ 2018-01-29 12:44 UTC (permalink / raw)
To: guix-devel
Hi,
as we've long talked and not really taken action on hardening builds
I've started working on an opt-in way as last discussed in
september 2016, modifying the gnu-build-system with a
#:hardening-flags keyword.
For my testing purposes I will use
> CFLAGS="-fPIE -fstack-protector-all -D_FORTIFY_SOURCE=2" LDFLAGS="-Wl,-z,now -Wl,-z,relro"
which is used by Gentoo, but adjustments (wether to opt-in or
opt-out) will be made.
--
ng0 :: https://ea.n0.is
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: hardening
2018-01-29 12:44 hardening ng0
@ 2018-01-29 19:21 ` Joshua Branson
2018-01-29 20:55 ` hardening ng0
2018-01-31 12:20 ` hardening Alex Vong
1 sibling, 1 reply; 22+ messages in thread
From: Joshua Branson @ 2018-01-29 19:21 UTC (permalink / raw)
To: guix-devel
Is this something anyone can start using now? Like I can modify my config.scm file somehow and start enjoying a hardened guix?
On Mon, Jan 29, 2018, at 4:44 AM, ng0@n0.is wrote:
> Hi,
>
> as we've long talked and not really taken action on hardening builds
> I've started working on an opt-in way as last discussed in
> september 2016, modifying the gnu-build-system with a
> #:hardening-flags keyword.
>
> For my testing purposes I will use
>
> > CFLAGS="-fPIE -fstack-protector-all -D_FORTIFY_SOURCE=2" LDFLAGS="-Wl,-z,now -Wl,-z,relro"
>
> which is used by Gentoo, but adjustments (wether to opt-in or
> opt-out) will be made.
> --
> ng0 :: https://ea.n0.is
> A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: hardening
2018-01-29 19:21 ` hardening Joshua Branson
@ 2018-01-29 20:55 ` ng0
0 siblings, 0 replies; 22+ messages in thread
From: ng0 @ 2018-01-29 20:55 UTC (permalink / raw)
To: guix-devel
Hi,
On Mon, 29 Jan 2018, Joshua Branson <jbranso@fastmail.com> wrote:
> Is this something anyone can start using now? Like I can modify my config.scm file somehow and start enjoying a hardened guix?
Sorry to disappoint you, I'd like to have it usable also right
now :) But: no. This takes some time and testing. I'll send
patches as soon as I have something to go with, today I only had
breakage on the bootstrap level ;)
> On Mon, Jan 29, 2018, at 4:44 AM, ng0@n0.is wrote:
>> Hi,
>>
>> as we've long talked and not really taken action on hardening builds
>> I've started working on an opt-in way as last discussed in
>> september 2016, modifying the gnu-build-system with a
>> #:hardening-flags keyword.
>>
>> For my testing purposes I will use
>>
>> > CFLAGS="-fPIE -fstack-protector-all -D_FORTIFY_SOURCE=2" LDFLAGS="-Wl,-z,now -Wl,-z,relro"
>>
>> which is used by Gentoo, but adjustments (wether to opt-in or
>> opt-out) will be made.
>> --
>> ng0 :: https://ea.n0.is
>> A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/
>>
>
>
--
ng0 :: https://ea.n0.is
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: hardening
2018-01-29 12:44 hardening ng0
2018-01-29 19:21 ` hardening Joshua Branson
@ 2018-01-31 12:20 ` Alex Vong
2018-03-11 13:37 ` hardening ng0
1 sibling, 1 reply; 22+ messages in thread
From: Alex Vong @ 2018-01-31 12:20 UTC (permalink / raw)
To: ng0; +Cc: guix-devel
Hello,
ng0@n0.is writes:
> Hi,
>
> as we've long talked and not really taken action on hardening builds
> I've started working on an opt-in way as last discussed in
> september 2016, modifying the gnu-build-system with a
> #:hardening-flags keyword.
>
> For my testing purposes I will use
>
>> CFLAGS="-fPIE -fstack-protector-all -D_FORTIFY_SOURCE=2"
> LDFLAGS="-Wl,-z,now -Wl,-z,relro"
>
> which is used by Gentoo, but adjustments (wether to opt-in or
> opt-out) will be made.
The flags I use (suggested by Debian Wiki[0]) are:
CPPFLAGS=-D_FORTIFY_SOURCE=2
CFLAGS=-fstack-protector-strong
CXXFLAGS=-fstack-protector-strong
LDFLAGS=-Wl,-z,relro,-z,now,--as-needed
Also, should we use retpoline flags for all native binaries? This
article[1] suggests ``applying a software mitigation (e.g., Google's
Retpoline) to the hypervisor, operating system kernel, system programs
and libraries, and user applications''. I've sent a patch to do so when
bootstraping GCC 7 itself[2] but no reply are received yet (maybe I
should have open a new bug instead of changing the title of an old
bug).
[0]: https://wiki.debian.org/Hardening
[1]: https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html
[2]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30111
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: hardening
2018-01-31 12:20 ` hardening Alex Vong
@ 2018-03-11 13:37 ` ng0
2018-03-11 13:40 ` hardening ng0
0 siblings, 1 reply; 22+ messages in thread
From: ng0 @ 2018-03-11 13:37 UTC (permalink / raw)
To: Alex Vong; +Cc: guix-devel, ng0
Alex Vong transcribed 1.3K bytes:
> Hello,
>
> ng0@n0.is writes:
>
> > Hi,
> >
> > as we've long talked and not really taken action on hardening builds
> > I've started working on an opt-in way as last discussed in
> > september 2016, modifying the gnu-build-system with a
> > #:hardening-flags keyword.
> >
> > For my testing purposes I will use
> >
> >> CFLAGS="-fPIE -fstack-protector-all -D_FORTIFY_SOURCE=2"
> > LDFLAGS="-Wl,-z,now -Wl,-z,relro"
> >
> > which is used by Gentoo, but adjustments (wether to opt-in or
> > opt-out) will be made.
>
> The flags I use (suggested by Debian Wiki[0]) are:
>
> CPPFLAGS=-D_FORTIFY_SOURCE=2
How does this differ from "-O2 -D_FORTIFY_SOURCE" in CFLAGS?
I know O2 is optimization and that FORTIFY_SOURCE requires optimization
to be specified.
> CFLAGS=-fstack-protector-strong
> CXXFLAGS=-fstack-protector-strong
> LDFLAGS=-Wl,-z,relro,-z,now,--as-needed
What are your opinions about:
-pipe -fPIE -fstack-shuffle -fstack-protector-all
> Also, should we use retpoline flags for all native binaries? This
> article[1] suggests ``applying a software mitigation (e.g., Google's
> Retpoline) to the hypervisor, operating system kernel, system programs
> and libraries, and user applications''. I've sent a patch to do so when
> bootstraping GCC 7 itself[2] but no reply are received yet (maybe I
> should have open a new bug instead of changing the title of an old
> bug).
>
> [0]: https://wiki.debian.org/Hardening
> [1]: https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html
> [2]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30111
>
--
A88C8ADD129828D7EAC02E52E22F9BBFEE348588
https://n0.is
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: hardening
2018-03-11 13:37 ` hardening ng0
@ 2018-03-11 13:40 ` ng0
2018-03-11 14:04 ` hardening Ricardo Wurmus
0 siblings, 1 reply; 22+ messages in thread
From: ng0 @ 2018-03-11 13:40 UTC (permalink / raw)
To: Alex Vong, guix-devel
ng0 transcribed 1.6K bytes:
> Alex Vong transcribed 1.3K bytes:
> > Hello,
> >
> > ng0@n0.is writes:
> >
> > > Hi,
> > >
> > > as we've long talked and not really taken action on hardening builds
> > > I've started working on an opt-in way as last discussed in
> > > september 2016, modifying the gnu-build-system with a
> > > #:hardening-flags keyword.
> > >
> > > For my testing purposes I will use
> > >
> > >> CFLAGS="-fPIE -fstack-protector-all -D_FORTIFY_SOURCE=2"
> > > LDFLAGS="-Wl,-z,now -Wl,-z,relro"
> > >
> > > which is used by Gentoo, but adjustments (wether to opt-in or
> > > opt-out) will be made.
> >
> > The flags I use (suggested by Debian Wiki[0]) are:
> >
> > CPPFLAGS=-D_FORTIFY_SOURCE=2
>
> How does this differ from "-O2 -D_FORTIFY_SOURCE" in CFLAGS?
> I know O2 is optimization and that FORTIFY_SOURCE requires optimization
> to be specified.
Okay, I've read some related commits and bug tickets, I understand
the difference now.
> > CFLAGS=-fstack-protector-strong
> > CXXFLAGS=-fstack-protector-strong
> > LDFLAGS=-Wl,-z,relro,-z,now,--as-needed
>
> What are your opinions about:
> -pipe -fPIE -fstack-shuffle -fstack-protector-all
>
> > Also, should we use retpoline flags for all native binaries? This
> > article[1] suggests ``applying a software mitigation (e.g., Google's
> > Retpoline) to the hypervisor, operating system kernel, system programs
> > and libraries, and user applications''. I've sent a patch to do so when
> > bootstraping GCC 7 itself[2] but no reply are received yet (maybe I
> > should have open a new bug instead of changing the title of an old
> > bug).
> >
> > [0]: https://wiki.debian.org/Hardening
> > [1]: https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html
> > [2]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30111
> >
>
> --
> A88C8ADD129828D7EAC02E52E22F9BBFEE348588
> https://n0.is
>
--
A88C8ADD129828D7EAC02E52E22F9BBFEE348588
https://n0.is
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: hardening
2018-03-11 13:40 ` hardening ng0
@ 2018-03-11 14:04 ` Ricardo Wurmus
2018-03-11 14:36 ` hardening ng0
0 siblings, 1 reply; 22+ messages in thread
From: Ricardo Wurmus @ 2018-03-11 14:04 UTC (permalink / raw)
To: ng0; +Cc: guix-devel
ng0 <ng0@n0.is> writes:
>> > The flags I use (suggested by Debian Wiki[0]) are:
>> >
>> > CPPFLAGS=-D_FORTIFY_SOURCE=2
>>
>> How does this differ from "-O2 -D_FORTIFY_SOURCE" in CFLAGS?
>> I know O2 is optimization and that FORTIFY_SOURCE requires optimization
>> to be specified.
>
> Okay, I've read some related commits and bug tickets, I understand
> the difference now.
Please share. Otherwise this comment isn’t really helpful for this
discussion.
--
Ricardo
^ permalink raw reply [flat|nested] 22+ messages in thread
* tor: update to 0.2.9.9
@ 2017-01-24 11:19 contact.ng0
2017-01-24 19:07 ` Leo Famulari
0 siblings, 1 reply; 22+ messages in thread
From: contact.ng0 @ 2017-01-24 11:19 UTC (permalink / raw)
To: guix-devel
This updates tor. I have seen no one prepare or commit a patch for this.
Paste from the announcement email:
Tor 0.2.9.9 fixes a denial-of-service bug where an attacker could
cause relays and clients to crash, even if they were not built with
the --enable-expensive-hardening option. This bug affects all 0.2.9.x
versions, and also affects 0.3.0.1-alpha: all relays running an affected
version should upgrade.
This release also resolves a client-side onion service reachability bug,
and resolves a pair of small portability issues.
Changes in version 0.2.9.9 - 2017-01-23
o Major bugfixes (security):
- Downgrade the "-ftrapv" option from "always on" to "only on when
--enable-expensive-hardening is provided." This hardening option,
like others, can turn survivable bugs into crashes -- and having
it on by default made a (relatively harmless) integer overflow bug
into a denial-of-service bug. Fixes bug 21278 (TROVE-2017-001);
bugfix on 0.2.9.1-alpha.
o Major bugfixes (client, onion service):
- Fix a client-side onion service reachability bug, where multiple
socks requests to an onion service (or a single slow request)
could cause us to mistakenly mark some of the service's
introduction points as failed, and we cache that failure so
eventually we run out and can't reach the service. Also resolves a
mysterious "Remote server sent bogus reason code 65021" log
warning. The bug was introduced in ticket 17218, where we tried to
remember the circuit end reason as a uint16_t, which mangled
negative values. Partially fixes bug 21056 and fixes bug 20307;
bugfix on 0.2.8.1-alpha.
o Minor features (geoip):
- Update geoip and geoip6 to the January 4 2017 Maxmind GeoLite2
Country database.
o Minor bugfixes (portability):
- Avoid crashing when Tor is built using headers that contain
CLOCK_MONOTONIC_COARSE, but then tries to run on an older kernel
without CLOCK_MONOTONIC_COARSE. Fixes bug 21035; bugfix
on 0.2.9.1-alpha.
- Fix Libevent detection on platforms without Libevent 1 headers
installed. Fixes bug 21051; bugfix on 0.2.9.1-alpha.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: tor: update to 0.2.9.9
2017-01-24 11:19 tor: update to 0.2.9.9 contact.ng0
@ 2017-01-24 19:07 ` Leo Famulari
2017-01-24 20:56 ` Hardening (was: Re: tor: update to 0.2.9.9) ng0
0 siblings, 1 reply; 22+ messages in thread
From: Leo Famulari @ 2017-01-24 19:07 UTC (permalink / raw)
To: contact.ng0; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 651 bytes --]
On Tue, Jan 24, 2017 at 11:19:33AM +0000, contact.ng0@cryptolab.net wrote:
> Changes in version 0.2.9.9 - 2017-01-23
> o Major bugfixes (security):
> - Downgrade the "-ftrapv" option from "always on" to "only on when
> --enable-expensive-hardening is provided." This hardening option,
> like others, can turn survivable bugs into crashes -- and having
> it on by default made a (relatively harmless) integer overflow bug
> into a denial-of-service bug. Fixes bug 21278 (TROVE-2017-001);
> bugfix on 0.2.9.1-alpha.
I'm not familiar with Tor's build system.
Should we build Tor with "--enable-expensive-hardening"?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Hardening (was: Re: tor: update to 0.2.9.9)
2017-01-24 19:07 ` Leo Famulari
@ 2017-01-24 20:56 ` ng0
2017-01-24 21:02 ` Leo Famulari
0 siblings, 1 reply; 22+ messages in thread
From: ng0 @ 2017-01-24 20:56 UTC (permalink / raw)
To: Leo Famulari; +Cc: guix-devel
Leo Famulari <leo@famulari.name> writes:
> On Tue, Jan 24, 2017 at 11:19:33AM +0000, contact.ng0@cryptolab.net wrote:
>> Changes in version 0.2.9.9 - 2017-01-23
>> o Major bugfixes (security):
>> - Downgrade the "-ftrapv" option from "always on" to "only on when
>> --enable-expensive-hardening is provided." This hardening option,
>> like others, can turn survivable bugs into crashes -- and having
>> it on by default made a (relatively harmless) integer overflow bug
>> into a denial-of-service bug. Fixes bug 21278 (TROVE-2017-001);
>> bugfix on 0.2.9.1-alpha.
>
> I'm not familiar with Tor's build system.
>
> Should we build Tor with "--enable-expensive-hardening"?
I will take a look later what can be applied other than the
default configure flags.
I'm all for hardening, but it seems that the first basic ideas
for Guix are stuck in the idea state.
It would be great to see some movement on this during this
year. I volunteer to help with it, though I don't have as much
experience with SELinux (and only basic experience with
GrSecurity without a modular kernel like GuixSD uses).
--
♥Ⓐ ng0 -- https://www.inventati.org/patternsinthechaos/
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Hardening (was: Re: tor: update to 0.2.9.9)
2017-01-24 20:56 ` Hardening (was: Re: tor: update to 0.2.9.9) ng0
@ 2017-01-24 21:02 ` Leo Famulari
2017-01-24 21:09 ` ng0
2017-01-25 9:09 ` Hardening (was: Re: tor: update to 0.2.9.9) Ricardo Wurmus
0 siblings, 2 replies; 22+ messages in thread
From: Leo Famulari @ 2017-01-24 21:02 UTC (permalink / raw)
To: ng0; +Cc: guix-devel
On Tue, Jan 24, 2017 at 08:56:48PM +0000, ng0 wrote:
> Leo Famulari <leo@famulari.name> writes:
> > Should we build Tor with "--enable-expensive-hardening"?
>
> I will take a look later what can be applied other than the
> default configure flags.
>
> I'm all for hardening, but it seems that the first basic ideas
> for Guix are stuck in the idea state.
As far as I can tell, --enable-expensive-hardening is specific to Tor,
so it's not relevant to the project of hardening all Guix packages.
> It would be great to see some movement on this during this
> year. I volunteer to help with it, though I don't have as much
> experience with SELinux (and only basic experience with
> GrSecurity without a modular kernel like GuixSD uses).
Yes, this effort needs a champion.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Hardening (was: Re: tor: update to 0.2.9.9)
2017-01-24 21:02 ` Leo Famulari
@ 2017-01-24 21:09 ` ng0
2017-01-24 21:18 ` ng0
2017-01-25 9:09 ` Hardening (was: Re: tor: update to 0.2.9.9) Ricardo Wurmus
1 sibling, 1 reply; 22+ messages in thread
From: ng0 @ 2017-01-24 21:09 UTC (permalink / raw)
To: Leo Famulari; +Cc: guix-devel
Leo Famulari <leo@famulari.name> writes:
> On Tue, Jan 24, 2017 at 08:56:48PM +0000, ng0 wrote:
>> Leo Famulari <leo@famulari.name> writes:
>> > Should we build Tor with "--enable-expensive-hardening"?
>>
>> I will take a look later what can be applied other than the
>> default configure flags.
>>
>> I'm all for hardening, but it seems that the first basic ideas
>> for Guix are stuck in the idea state.
>
> As far as I can tell, --enable-expensive-hardening is specific to Tor,
> so it's not relevant to the project of hardening all Guix packages.
Yes.
I'm building this change right now:
+ (arguments
+ `(#:configure-flags (list "--enable-expensive-hardening"
+ "--enable-gcc-hardening"
+ "--enable-linker-hardening")))
Taken from Gentoo, I trust their hardening project to debug and
discover good usage.
>> It would be great to see some movement on this during this
>> year. I volunteer to help with it, though I don't have as much
>> experience with SELinux (and only basic experience with
>> GrSecurity without a modular kernel like GuixSD uses).
>
> Yes, this effort needs a champion.
--
♥Ⓐ ng0 -- https://www.inventati.org/patternsinthechaos/
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Hardening (was: Re: tor: update to 0.2.9.9)
2017-01-24 21:09 ` ng0
@ 2017-01-24 21:18 ` ng0
2017-01-24 21:32 ` Leo Famulari
0 siblings, 1 reply; 22+ messages in thread
From: ng0 @ 2017-01-24 21:18 UTC (permalink / raw)
To: guix-devel
ng0 <contact.ng0@cryptolab.net> writes:
> Leo Famulari <leo@famulari.name> writes:
>
>> On Tue, Jan 24, 2017 at 08:56:48PM +0000, ng0 wrote:
>>> Leo Famulari <leo@famulari.name> writes:
>>> > Should we build Tor with "--enable-expensive-hardening"?
>>>
>>> I will take a look later what can be applied other than the
>>> default configure flags.
>>>
>>> I'm all for hardening, but it seems that the first basic ideas
>>> for Guix are stuck in the idea state.
>>
>> As far as I can tell, --enable-expensive-hardening is specific to Tor,
>> so it's not relevant to the project of hardening all Guix packages.
>
> Yes.
>
> I'm building this change right now:
>
> + (arguments
> + `(#:configure-flags (list "--enable-expensive-hardening"
> + "--enable-gcc-hardening"
> + "--enable-linker-hardening")))
>
> Taken from Gentoo, I trust their hardening project to debug and
> discover good usage.
>
>>> It would be great to see some movement on this during this
>>> year. I volunteer to help with it, though I don't have as much
>>> experience with SELinux (and only basic experience with
>>> GrSecurity without a modular kernel like GuixSD uses).
>>
>> Yes, this effort needs a champion.
No, I would say this needs an effort of more than one person. At
best a team of people who either are willing to learn about
system hardening or already know enough, maybe even a combination
of both to share knowledge :)
--
♥Ⓐ ng0 -- https://www.inventati.org/patternsinthechaos/
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Hardening (was: Re: tor: update to 0.2.9.9)
2017-01-24 21:18 ` ng0
@ 2017-01-24 21:32 ` Leo Famulari
2017-01-24 21:56 ` ng0
0 siblings, 1 reply; 22+ messages in thread
From: Leo Famulari @ 2017-01-24 21:32 UTC (permalink / raw)
To: ng0; +Cc: guix-devel
On Tue, Jan 24, 2017 at 09:18:55PM +0000, ng0 wrote:
> ng0 <contact.ng0@cryptolab.net> writes:
> > Leo Famulari <leo@famulari.name> writes:
> >>> It would be great to see some movement on this during this
> >>> year. I volunteer to help with it, though I don't have as much
> >>> experience with SELinux (and only basic experience with
> >>> GrSecurity without a modular kernel like GuixSD uses).
> >>
> >> Yes, this effort needs a champion.
>
> No, I would say this needs an effort of more than one person. At
> best a team of people who either are willing to learn about
> system hardening or already know enough, maybe even a combination
> of both to share knowledge :)
Sure, the more people the better. But so far, not a single person has
begun working on it, so I'd be happy with just one.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Hardening (was: Re: tor: update to 0.2.9.9)
2017-01-24 21:32 ` Leo Famulari
@ 2017-01-24 21:56 ` ng0
2017-01-25 13:04 ` Hardening Ludovic Courtès
0 siblings, 1 reply; 22+ messages in thread
From: ng0 @ 2017-01-24 21:56 UTC (permalink / raw)
To: Leo Famulari; +Cc: guix-devel
Leo Famulari <leo@famulari.name> writes:
> On Tue, Jan 24, 2017 at 09:18:55PM +0000, ng0 wrote:
>> ng0 <contact.ng0@cryptolab.net> writes:
>> > Leo Famulari <leo@famulari.name> writes:
>> >>> It would be great to see some movement on this during this
>> >>> year. I volunteer to help with it, though I don't have as much
>> >>> experience with SELinux (and only basic experience with
>> >>> GrSecurity without a modular kernel like GuixSD uses).
>> >>
>> >> Yes, this effort needs a champion.
>>
>> No, I would say this needs an effort of more than one person. At
>> best a team of people who either are willing to learn about
>> system hardening or already know enough, maybe even a combination
>> of both to share knowledge :)
>
> Sure, the more people the better. But so far, not a single person has
> begun working on it, so I'd be happy with just one.
I feel confident enough to do it, but I also know that I am
overloaded with packages and services I work on.
For starters, I think we could have an "hardened-wip" branch on
savannah (I can't commit anyway directly) and that we can target
SELinux for now, look at Hardened-gentoo and other systems how
they solve issues. Afterwards we need to address the toolchain
level, which to our advantage can be an make and break by hydra
and everyone who wants to contribute to fixing issues can run
their system from the hardening-toolchain-wip branch to
contribute to fixing all the breaking applications.
Then we need to discuss wether we want to provide this by default
(my choice) OR if we want to offer a branch-choice model.
Supporting both vanilla and hardened might take some more burden
on fixing issues, that's why I'm all for forming a team of people
who work on this, and when they no longer want to, other people
join the rest of the old team, etc.
Right now I'm trying to get uclib-ng done for a while, and when
this is added, we could at some point handle more than one
toolchain (and hardened), where it gets complicated.
--
♥Ⓐ ng0 -- https://www.inventati.org/patternsinthechaos/
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Hardening
2017-01-24 21:56 ` ng0
@ 2017-01-25 13:04 ` Ludovic Courtès
2017-01-30 12:05 ` Hardening ng0
0 siblings, 1 reply; 22+ messages in thread
From: Ludovic Courtès @ 2017-01-25 13:04 UTC (permalink / raw)
To: ng0; +Cc: guix-devel
Hi!
ng0 <contact.ng0@cryptolab.net> skribis:
> For starters, I think we could have an "hardened-wip" branch on
> savannah (I can't commit anyway directly) and that we can target
> SELinux for now, look at Hardened-gentoo and other systems how
> they solve issues. Afterwards we need to address the toolchain
> level, which to our advantage can be an make and break by hydra
> and everyone who wants to contribute to fixing issues can run
> their system from the hardening-toolchain-wip branch to
> contribute to fixing all the breaking applications.
>
> Then we need to discuss wether we want to provide this by default
> (my choice) OR if we want to offer a branch-choice model.
> Supporting both vanilla and hardened might take some more burden
> on fixing issues, that's why I'm all for forming a team of people
> who work on this, and when they no longer want to, other people
> join the rest of the old team, etc.
Before creating a branch, I think we need a plan. :-)
Alex Vong proposed ways to achieve it a while back:
https://lists.gnu.org/archive/html/guix-devel/2015-12/msg00702.html
I suggest taking a look at the discussion and starting from there.
The best option is probably to start small (limited set of
features/flags/options) and then incrementally improve that.
Ludo’.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Hardening
2017-01-25 13:04 ` Hardening Ludovic Courtès
@ 2017-01-30 12:05 ` ng0
2017-01-30 12:16 ` Hardening ng0
0 siblings, 1 reply; 22+ messages in thread
From: ng0 @ 2017-01-30 12:05 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
Ludovic Courtès <ludo@gnu.org> writes:
> Hi!
>
> ng0 <contact.ng0@cryptolab.net> skribis:
>
>> For starters, I think we could have an "hardened-wip" branch on
>> savannah (I can't commit anyway directly) and that we can target
>> SELinux for now, look at Hardened-gentoo and other systems how
>> they solve issues. Afterwards we need to address the toolchain
>> level, which to our advantage can be an make and break by hydra
>> and everyone who wants to contribute to fixing issues can run
>> their system from the hardening-toolchain-wip branch to
>> contribute to fixing all the breaking applications.
>>
>> Then we need to discuss wether we want to provide this by default
>> (my choice) OR if we want to offer a branch-choice model.
>> Supporting both vanilla and hardened might take some more burden
>> on fixing issues, that's why I'm all for forming a team of people
>> who work on this, and when they no longer want to, other people
>> join the rest of the old team, etc.
>
> Before creating a branch, I think we need a plan. :-)
>
> Alex Vong proposed ways to achieve it a while back:
>
> https://lists.gnu.org/archive/html/guix-devel/2015-12/msg00702.html
>
> I suggest taking a look at the discussion and starting from there.
Okay, I did and I don't see right now how this new (guix build
build-flags) module would be applied to the gnu build system for
example.
Would the (gnu build system) just use it somehow? I'd like to
test it, but I didn't write it.
I also would like to rename it to (guix build build-flags-glibc)
(or -gcc) as I want to see a point where we have more than just
glibc. We don't have to build them (the substitutes,packages) all
on hydra. musl and uclibc-ng can be without substitutes as long
as the means of distribution or diskspace are not working out for us.
And both can (and will) get hardened builds aswell.
> The best option is probably to start small (limited set of
> features/flags/options) and then incrementally improve that.
>
> Ludo’.
--
ng0 -- https://www.inventati.org/patternsinthechaos/
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Hardening
2017-01-30 12:05 ` Hardening ng0
@ 2017-01-30 12:16 ` ng0
0 siblings, 0 replies; 22+ messages in thread
From: ng0 @ 2017-01-30 12:16 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
ng0 <contact.ng0@cryptolab.net> writes:
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hi!
>>
>> ng0 <contact.ng0@cryptolab.net> skribis:
>>
>>> For starters, I think we could have an "hardened-wip" branch on
>>> savannah (I can't commit anyway directly) and that we can target
>>> SELinux for now, look at Hardened-gentoo and other systems how
>>> they solve issues. Afterwards we need to address the toolchain
>>> level, which to our advantage can be an make and break by hydra
>>> and everyone who wants to contribute to fixing issues can run
>>> their system from the hardening-toolchain-wip branch to
>>> contribute to fixing all the breaking applications.
>>>
>>> Then we need to discuss wether we want to provide this by default
>>> (my choice) OR if we want to offer a branch-choice model.
>>> Supporting both vanilla and hardened might take some more burden
>>> on fixing issues, that's why I'm all for forming a team of people
>>> who work on this, and when they no longer want to, other people
>>> join the rest of the old team, etc.
>>
>> Before creating a branch, I think we need a plan. :-)
>>
>> Alex Vong proposed ways to achieve it a while back:
>>
>> https://lists.gnu.org/archive/html/guix-devel/2015-12/msg00702.html
>>
>> I suggest taking a look at the discussion and starting from there.
>
> Okay, I did and I don't see right now how this new (guix build
> build-flags) module would be applied to the gnu build system for
> example.
> Would the (gnu build system) just use it somehow? I'd like to
> test it, but I didn't write it.
Sorry, correction:
I must have skipped the explanation at the beginning, I do
understand it.
And it makes sense… it's in the interest of my blend of GuixSD,
so unless someone really has a burning desire to work on this, I
will try to produce something functional with changes to the
build system(s) to use hardened flags by default, with opt-out
for: other build-systems I do not understand, and whatnot.
There's no harm in not providing something like:
#:hardened? #f
for those applications which still need to be patched, but I
prefer to fix rather than provide the easy way out.
> I also would like to rename it to (guix build build-flags-glibc)
> (or -gcc) as I want to see a point where we have more than just
> glibc. We don't have to build them (the substitutes,packages) all
> on hydra. musl and uclibc-ng can be without substitutes as long
> as the means of distribution or diskspace are not working out for us.
> And both can (and will) get hardened builds aswell.
>
>> The best option is probably to start small (limited set of
>> features/flags/options) and then incrementally improve that.
>>
>> Ludo’.
>
> --
> ng0 -- https://www.inventati.org/patternsinthechaos/
--
ng0 -- https://www.inventati.org/patternsinthechaos/
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Hardening (was: Re: tor: update to 0.2.9.9)
2017-01-24 21:02 ` Leo Famulari
2017-01-24 21:09 ` ng0
@ 2017-01-25 9:09 ` Ricardo Wurmus
2017-01-25 11:51 ` Hardening ng0
1 sibling, 1 reply; 22+ messages in thread
From: Ricardo Wurmus @ 2017-01-25 9:09 UTC (permalink / raw)
To: Leo Famulari; +Cc: guix-devel
Leo Famulari <leo@famulari.name> writes:
> On Tue, Jan 24, 2017 at 08:56:48PM +0000, ng0 wrote:
>> Leo Famulari <leo@famulari.name> writes:
>> > Should we build Tor with "--enable-expensive-hardening"?
>>
>> I will take a look later what can be applied other than the
>> default configure flags.
>>
>> I'm all for hardening, but it seems that the first basic ideas
>> for Guix are stuck in the idea state.
>
> As far as I can tell, --enable-expensive-hardening is specific to Tor,
> so it's not relevant to the project of hardening all Guix packages.
>
>> It would be great to see some movement on this during this
>> year. I volunteer to help with it, though I don't have as much
>> experience with SELinux (and only basic experience with
>> GrSecurity without a modular kernel like GuixSD uses).
>
> Yes, this effort needs a champion.
I know SELinux and I have a couple of almost-ready packages for it. The
bigger problem for us is writing SELinux policies, because we cannot
just use those from Fedora.
SELinux policies are applied to file paths (which are not stable in
Guix) and are “remembered” using extended file attributes. This means
we’d have to write policies that can deal with arbitrary prefixes and
we’d have to add an optional service to automatically label all store
items (that’s expensive but maybe it can be done incrementally).
However, this is completely separate from enabling a configure flag for
Tor.
--
Ricardo
GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
https://elephly.net
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Hardening
2017-01-25 9:09 ` Hardening (was: Re: tor: update to 0.2.9.9) Ricardo Wurmus
@ 2017-01-25 11:51 ` ng0
0 siblings, 0 replies; 22+ messages in thread
From: ng0 @ 2017-01-25 11:51 UTC (permalink / raw)
To: guix-devel
Ricardo Wurmus <rekado@elephly.net> writes:
> Leo Famulari <leo@famulari.name> writes:
>
>> On Tue, Jan 24, 2017 at 08:56:48PM +0000, ng0 wrote:
>>> Leo Famulari <leo@famulari.name> writes:
>>> > Should we build Tor with "--enable-expensive-hardening"?
>>>
>>> I will take a look later what can be applied other than the
>>> default configure flags.
>>>
>>> I'm all for hardening, but it seems that the first basic ideas
>>> for Guix are stuck in the idea state.
>>
>> As far as I can tell, --enable-expensive-hardening is specific to Tor,
>> so it's not relevant to the project of hardening all Guix packages.
>>
>>> It would be great to see some movement on this during this
>>> year. I volunteer to help with it, though I don't have as much
>>> experience with SELinux (and only basic experience with
>>> GrSecurity without a modular kernel like GuixSD uses).
>>
>> Yes, this effort needs a champion.
>
> I know SELinux and I have a couple of almost-ready packages for it. The
> bigger problem for us is writing SELinux policies, because we cannot
> just use those from Fedora.
Oh, this is good to hear!
> SELinux policies are applied to file paths (which are not stable in
> Guix) and are “remembered” using extended file attributes. This means
> we’d have to write policies that can deal with arbitrary prefixes and
> we’d have to add an optional service to automatically label all store
> items (that’s expensive but maybe it can be done incrementally).
Oh.
> However, this is completely separate from enabling a configure flag for
> Tor.
That's why I changed the subject of the email, I am aware that
this has nothing to do with tor configure-flags.
--
♥Ⓐ ng0 -- https://www.inventati.org/patternsinthechaos/
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 1/2] Add (guix build build-flags).
@ 2015-10-31 13:56 Alex Vong
2015-11-05 21:55 ` Ludovic Courtès
0 siblings, 1 reply; 22+ messages in thread
From: Alex Vong @ 2015-10-31 13:56 UTC (permalink / raw)
To: guix-devel
From 6ad35e245c374ff828f167bb3467ce68559ccefd Mon Sep 17 00:00:00 2001
From: Alex Vong <alexvong1995@gmail.com>
Date: Sat, 31 Oct 2015 19:44:13 +0800
Subject: [PATCH 1/2] Add (guix build build-flags).
A module to manipulate build flags, similar to dpkg-buildflags.
* guix/build/build-flags.scm: New file.
* Makefile.am (MODULES): Register it.
---
Makefile.am | 1 +
guix/build/build-flags.scm | 271 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 272 insertions(+)
create mode 100644 guix/build/build-flags.scm
diff --git a/Makefile.am b/Makefile.am
index b2ee324..c62cb8b 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -71,6 +71,7 @@ MODULES = \
guix/svn-download.scm \
guix/ui.scm \
guix/build/download.scm \
+ guix/build/build-flags.scm \
guix/build/cmake-build-system.scm \
guix/build/emacs-build-system.scm \
guix/build/git.scm \
diff --git a/guix/build/build-flags.scm b/guix/build/build-flags.scm
new file mode 100644
index 0000000..30a35a1
--- /dev/null
+++ b/guix/build/build-flags.scm
@@ -0,0 +1,271 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2015 Alex Vong <alexvong1995@gmail.com>
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
+
+(define-module (guix build build-flags)
+ #:use-module (srfi srfi-1)
+ #:use-module (srfi srfi-9)
+ #:export (flag-list
+ flag-list+
+ flag-list-
+ flag-list->string-list
+ default-flag-list
+ format-flag-list
+ fortify-flag-list
+ stackprotector-flag-list
+ stackprotectorstrong-flag-list
+ relro-flag-list
+ bindnow-flag-list
+ pie-flag-list
+ all-flag-list))
+
+;;; Commentary:
+;;;
+;;; Module to manipulate build flags, similar to dpkg-buildflags.
+;;;
+;;; Data structure <flag-list> is constructed by flag-list.
+;;; The constructor flag-list does something to its arguments,
+;;; such as trimming white-spaces, to ensure no two arguments mean the same.
+;;;
+;;; Here is an example:
+;;; (define default-flag-list
+;;; (flag-list
+;;; #:CFLAGS '("-O2" "-g")
+;;; #:LDFLAGS '("-lm" "-lpthread")))
+;;;
+;;; flag-list+ and flag-list- are analogous to
+;;; numeric + and - but operate on <flag-list>.
+;;;
+;;; flag-list->string-list converts <flag-list> into
+;;; configure-flags-compatible string-list.
+;;;
+;;; Code:
+
+
+;;; Pair up a symbol with a procedure so that we know
+;;; what identifier is bound to the procedure at macro-expand time.
+(define-record-type <identifier-procedure-pair>
+ (cons-identifier-procedure id proc)
+ identifier-procedure-pair?
+ (id identifier)
+ (proc procedure))
+
+(define-syntax define-record-type-with-accessor-list
+ (syntax-rules ()
+ "Macro to define a srfi-9 record
+with accessor list bound to accessor-list-name.
+"
+ ((_ record-name
+ (constructor-name field-name* ...)
+ predicate-name
+ accessor-list-name
+ (field-name accessor-name) ...)
+ (begin
+ (define-record-type record-name
+ (constructor-name field-name* ...)
+ predicate-name
+ (field-name accessor-name) ...)
+ (define accessor-list-name
+ `(,(cons-identifier-procedure 'accessor-name
+ accessor-name) ...))))))
+
+;;; define <flag-list> using define-record-type-with-accessor-list macro
+(define-record-type-with-accessor-list <flag-list>
+ (make-flag-list c-flags
+ cpp-flags
+ c++-flags
+ fc-flags
+ f-flags
+ gcj-flags
+ ld-flags
+ objc-flags
+ objc++-flags)
+ flag-list?
+ flag-list-accessor-list
+ (c-flags CFLAGS)
+ (cpp-flags CPPFLAGS)
+ (c++-flags CXXFLAGS)
+ (fc-flags FCFLAGS)
+ (f-flags FFLAGS)
+ (gcj-flags GCJFLAGS)
+ (ld-flags LDFLAGS)
+ (objc-flags OBJCFLAGS)
+ (objc++-flags OBJCXXFLAGS))
+
+
+(define-syntax define*-with-keyword-list
+ (syntax-rules ()
+ "Macro to define a procedure with keyword and default arguments
+only with keyword list bound to keyword-list-name.
+"
+ ((_ (proc-name keyword-list-name
+ (keyword default-val) ...)
+ body)
+ (begin
+ (define* (proc-name #:key
+ (keyword default-val) ...)
+ body)
+ (define keyword-list-name
+ (map symbol->keyword
+ '(keyword ...)))))))
+
+;;; Constructor for <flag-list>
+;;; with keyword list bound to flag-list-keyword-list.
+(define*-with-keyword-list (flag-list flag-list-keyword-list
+ (CFLAGS '())
+ (CPPFLAGS '())
+ (CXXFLAGS '())
+ (FCFLAGS '())
+ (FFLAGS '())
+ (GCJFLAGS '())
+ (LDFLAGS '())
+ (OBJCFLAGS '())
+ (OBJCXXFLAGS '()))
+ (apply make-flag-list
+ (map (lambda (string-list)
+ (map string-trim-both string-list))
+ (list CFLAGS
+ CPPFLAGS
+ CXXFLAGS
+ FCFLAGS
+ FFLAGS
+ GCJFLAGS
+ LDFLAGS
+ OBJCFLAGS
+ OBJCXXFLAGS))))
+
+(define (keyword-apply proc kw-list kw-arg-list by-position-arg-list)
+ "keyword-apply is inspired by the same-name procedure in Racket.
+It applies a procedure using keyword list and keyword argument list.
+"
+ (apply proc
+ (append (concatenate (zip kw-list
+ kw-arg-list))
+ by-position-arg-list)))
+
+
+(define (flag-list-operation lset-operation)
+ "Take a lset operation.
+Return a procedure that takes any number of <flag-list>
+and does the set operation on them for each flags respectively
+"
+ (define (list-of-string-list-operation list-of-string-list)
+ (apply lset-operation
+ `(,string=? ,@list-of-string-list)))
+ (lambda list-of-flag-list
+ (let ((flag-list-proc-list (map procedure
+ flag-list-accessor-list)))
+ (keyword-apply flag-list
+ flag-list-keyword-list
+ (map (lambda (proc)
+ (list-of-string-list-operation
+ (map proc list-of-flag-list)))
+ flag-list-proc-list)
+ '()))))
+
+;;; union any number of <flag-list> for each flags
+(define flag-list+
+ (flag-list-operation lset-union))
+
+;;; take the first <flag-list> and minus the union of the rest for each flags
+(define flag-list-
+ (flag-list-operation lset-difference))
+
+(define (flag-list->string-list flag-lst)
+ "Convert <flag-list> into configure-flags-compatible string list.
+"
+ (map (lambda (accessor)
+ (let ((id (identifier accessor))
+ (proc (procedure accessor)))
+ (string-append (symbol->string id)
+ "="
+ (string-join (proc flag-lst)))))
+ flag-list-accessor-list))
+
+
+;;; build flags used in dpkg-buildflags
+
+(define default-flag-list
+ (flag-list
+ #:CFLAGS '("-g" "-O2")
+ #:CXXFLAGS '("-g" "-O2")
+ #:FCFLAGS '("-g" "-O2")
+ #:FFLAGS '("-g" "-O2")
+ #:GCJFLAGS '("-g" "-O2")
+ #:OBJCFLAGS '("-g" "-O2")
+ #:OBJCXXFLAGS '("-g" "-O2")))
+
+(define format-flag-list
+ (flag-list
+ #:CFLAGS '("-Wformat" "-Werror=format-security")
+ #:CXXFLAGS '("-Wformat" "-Werror=format-security")
+ #:OBJCFLAGS '("-Wformat" "-Werror=format-security")
+ #:OBJCXXFLAGS '("-Wformat" "-Werror=format-security")))
+
+(define fortify-flag-list
+ (flag-list
+ #:CPPFLAGS '("-D_FORTIFY_SOURCE=2")))
+
+(define stackprotector-flag-list
+ (flag-list
+ #:CFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
+ #:CXXFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
+ #:FCFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
+ #:FFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
+ #:GCJFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
+ #:OBJCFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
+ #:OBJCXXFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")))
+
+(define stackprotectorstrong-flag-list
+ (flag-list
+ #:CFLAGS '("-fstack-protector-strong")
+ #:CXXFLAGS '("-fstack-protector-strong")
+ #:FCFLAGS '("-fstack-protector-strong")
+ #:FFLAGS '("-fstack-protector-strong")
+ #:GCJFLAGS '("-fstack-protector-strong")
+ #:OBJCFLAGS '("-fstack-protector-strong")
+ #:OBJCXXFLAGS '("-fstack-protector-strong")))
+
+(define relro-flag-list
+ (flag-list
+ #:LDFLAGS '("-Wl,-z,relro")))
+
+(define bindnow-flag-list
+ (flag-list
+ #:LDFLAGS '("-Wl,-z,now")))
+
+(define pie-flag-list
+ (flag-list
+ #:CFLAGS '("-fPIE")
+ #:CXXFLAGS '("-fPIE")
+ #:FCFLAGS '("-fPIE")
+ #:FFLAGS '("-fPIE")
+ #:GCJFLAGS '("-fPIE")
+ #:LDFLAGS '("-fPIE" "-pie")
+ #:OBJCFLAGS '("-fPIE")
+ #:OBJCXXFLAGS '("-fPIE")))
+
+(define all-flag-list
+ (flag-list+ default-flag-list
+ format-flag-list
+ fortify-flag-list
+ stackprotectorstrong-flag-list
+ relro-flag-list
+ bindnow-flag-list
+ pie-flag-list))
+
+;;; build-flags.scm ends here
--
2.1.4
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] Add (guix build build-flags).
2015-10-31 13:56 [PATCH 1/2] Add (guix build build-flags) Alex Vong
@ 2015-11-05 21:55 ` Ludovic Courtès
2015-12-25 15:38 ` Alex Vong
0 siblings, 1 reply; 22+ messages in thread
From: Ludovic Courtès @ 2015-11-05 21:55 UTC (permalink / raw)
To: Alex Vong; +Cc: guix-devel
Alex Vong <alexvong1995@gmail.com> skribis:
> From 6ad35e245c374ff828f167bb3467ce68559ccefd Mon Sep 17 00:00:00 2001
> From: Alex Vong <alexvong1995@gmail.com>
> Date: Sat, 31 Oct 2015 19:44:13 +0800
> Subject: [PATCH 1/2] Add (guix build build-flags).
>
> A module to manipulate build flags, similar to dpkg-buildflags.
>
> * guix/build/build-flags.scm: New file.
> * Makefile.am (MODULES): Register it.
[...]
> +;;; Module to manipulate build flags, similar to dpkg-buildflags.
It doesn’t really help to refer to dpkg-buildflags, at least for me. ;-)
> +;;; Data structure <flag-list> is constructed by flag-list.
> +;;; The constructor flag-list does something to its arguments,
> +;;; such as trimming white-spaces, to ensure no two arguments mean the same.
> +;;;
> +;;; Here is an example:
> +;;; (define default-flag-list
> +;;; (flag-list
> +;;; #:CFLAGS '("-O2" "-g")
> +;;; #:LDFLAGS '("-lm" "-lpthread")))
> +;;;
> +;;; flag-list+ and flag-list- are analogous to
> +;;; numeric + and - but operate on <flag-list>.
> +;;;
> +;;; flag-list->string-list converts <flag-list> into
> +;;; configure-flags-compatible string-list.
How would we use flag lists?
The problem is that each build system has its own way to specify custom
flags, and some don’t even allow that. So being able to manipulate flag
lists is nice, but I’m afraid we wouldn’t be able to make much out of
them.
WDYT?
> +(define-syntax define-record-type-with-accessor-list
> + (syntax-rules ()
> + "Macro to define a srfi-9 record
> +with accessor list bound to accessor-list-name.
Is this really needed? Would ‘define-record-type*’ from (guix records)
do the job?
> +(define-record-type-with-accessor-list <flag-list>
> + (make-flag-list c-flags
> + cpp-flags
> + c++-flags
> + fc-flags
> + f-flags
> + gcj-flags
> + ld-flags
> + objc-flags
> + objc++-flags)
I’m not convinced we need to list all these flags, but again, that
depends on how we end up using it.
On one hand that’s already too many flags, and we’d be passing the same
options to all of them anyway–like -fstack-protector, -fPIE, etc.
On the other hand, it’s very much GCC- and autotool-centric.
[...]
> +(define fortify-flag-list
> + (flag-list
> + #:CPPFLAGS '("-D_FORTIFY_SOURCE=2")))
> +
> +(define stackprotector-flag-list
> + (flag-list
> + #:CFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
> + #:CXXFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
> + #:FCFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
> + #:FFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
> + #:GCJFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
> + #:OBJCFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
> + #:OBJCXXFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")))
> +
> +(define stackprotectorstrong-flag-list
> + (flag-list
> + #:CFLAGS '("-fstack-protector-strong")
> + #:CXXFLAGS '("-fstack-protector-strong")
> + #:FCFLAGS '("-fstack-protector-strong")
> + #:FFLAGS '("-fstack-protector-strong")
> + #:GCJFLAGS '("-fstack-protector-strong")
> + #:OBJCFLAGS '("-fstack-protector-strong")
> + #:OBJCXXFLAGS '("-fstack-protector-strong")))
I’ve been thinking we should experiment with these various options. The
way I’d do it now would be by running:
./configure x y z CPPFLAGS=-D_FORTIFY_SOURCE=2 CFLAGS=-fstack-protector
This would be just automatically added to #:configure-flags in
gnu-build-system.scm.
Of course, some packages would ignore them and others would break, but
that’s part of the game. It largely have to be approached on a
case-by-case basis.
Thoughts?
Ludo’.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] Add (guix build build-flags).
2015-11-05 21:55 ` Ludovic Courtès
@ 2015-12-25 15:38 ` Alex Vong
2015-12-30 16:06 ` Hardening Ludovic Courtès
0 siblings, 1 reply; 22+ messages in thread
From: Alex Vong @ 2015-12-25 15:38 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
ludo@gnu.org (Ludovic Courtès) writes:
Hi,
This is an old thread, but I am still unclear of something, so I will
reply.
> Alex Vong <alexvong1995@gmail.com> skribis:
>
>> From 6ad35e245c374ff828f167bb3467ce68559ccefd Mon Sep 17 00:00:00 2001
>> From: Alex Vong <alexvong1995@gmail.com>
>> Date: Sat, 31 Oct 2015 19:44:13 +0800
>> Subject: [PATCH 1/2] Add (guix build build-flags).
>>
>> A module to manipulate build flags, similar to dpkg-buildflags.
>>
>> * guix/build/build-flags.scm: New file.
>> * Makefile.am (MODULES): Register it.
>
> [...]
>
>> +;;; Module to manipulate build flags, similar to dpkg-buildflags.
>
> It doesn’t really help to refer to dpkg-buildflags, at least for me. ;-)
>
Sure, I should have elaborated more on it. What I am looking for are
ways to avoid repeating a lot of flags in different packages, something
like `use this set of flags, please'. For example, in Debian, if you
type
$ dpkg-buildflags --get CFLAGS
you get
-g -O2 -fstack-protector-strong -Wformat -Werror=format-security
which are thr default flags to be exported during package
build. Moroever, maintainer can alter the default behaviour by setting
DEB_BUILD_MAINT_OPTIONS. For example,
$ DEB_BUILD_MAINT_OPTIONS=hardening=+all dpkg-buildflags --get CFLAGS
will return
-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security
>> +;;; Data structure <flag-list> is constructed by flag-list.
>> +;;; The constructor flag-list does something to its arguments,
>> +;;; such as trimming white-spaces, to ensure no two arguments mean the same.
>> +;;;
>> +;;; Here is an example:
>> +;;; (define default-flag-list
>> +;;; (flag-list
>> +;;; #:CFLAGS '("-O2" "-g")
>> +;;; #:LDFLAGS '("-lm" "-lpthread")))
>> +;;;
>> +;;; flag-list+ and flag-list- are analogous to
>> +;;; numeric + and - but operate on <flag-list>.
>> +;;;
>> +;;; flag-list->string-list converts <flag-list> into
>> +;;; configure-flags-compatible string-list.
>
> How would we use flag lists?
>
> The problem is that each build system has its own way to specify custom
> flags, and some don’t even allow that. So being able to manipulate flag
> lists is nice, but I’m afraid we wouldn’t be able to make much out of
> them.
>
> WDYT?
>
>> +(define-syntax define-record-type-with-accessor-list
>> + (syntax-rules ()
>> + "Macro to define a srfi-9 record
>> +with accessor list bound to accessor-list-name.
>
> Is this really needed? Would ‘define-record-type*’ from (guix records)
> do the job?
>
>> +(define-record-type-with-accessor-list <flag-list>
>> + (make-flag-list c-flags
>> + cpp-flags
>> + c++-flags
>> + fc-flags
>> + f-flags
>> + gcj-flags
>> + ld-flags
>> + objc-flags
>> + objc++-flags)
>
> I’m not convinced we need to list all these flags, but again, that
> depends on how we end up using it.
>
> On one hand that’s already too many flags, and we’d be passing the same
> options to all of them anyway–like -fstack-protector, -fPIE, etc.
>
> On the other hand, it’s very much GCC- and autotool-centric.
>
> [...]
>
>> +(define fortify-flag-list
>> + (flag-list
>> + #:CPPFLAGS '("-D_FORTIFY_SOURCE=2")))
>> +
>> +(define stackprotector-flag-list
>> + (flag-list
>> + #:CFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
>> + #:CXXFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
>> + #:FCFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
>> + #:FFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
>> + #:GCJFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
>> + #:OBJCFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")
>> + #:OBJCXXFLAGS '("-fstack-protector" "--param=ssp-buffer-size=4")))
>> +
>> +(define stackprotectorstrong-flag-list
>> + (flag-list
>> + #:CFLAGS '("-fstack-protector-strong")
>> + #:CXXFLAGS '("-fstack-protector-strong")
>> + #:FCFLAGS '("-fstack-protector-strong")
>> + #:FFLAGS '("-fstack-protector-strong")
>> + #:GCJFLAGS '("-fstack-protector-strong")
>> + #:OBJCFLAGS '("-fstack-protector-strong")
>> + #:OBJCXXFLAGS '("-fstack-protector-strong")))
>
> I’ve been thinking we should experiment with these various options. The
> way I’d do it now would be by running:
>
> ./configure x y z CPPFLAGS=-D_FORTIFY_SOURCE=2 CFLAGS=-fstack-protector
>
> This would be just automatically added to #:configure-flags in
> gnu-build-system.scm.
>
> Of course, some packages would ignore them and others would break, but
> that’s part of the game. It largely have to be approached on a
> case-by-case basis.
>
Yes, I grep for `fstack-protector-strong' in the guix code base and no
matches are found. It appears no packages are setting this flag
currently. I think this flag (perhaps also a couple others) should be
set by default since they help protect against buffer overflow
<https://en.wikipedia.org/wiki/Buffer_overflow_protection>.
> Thoughts?
>
> Ludo’.
How do you people think?
Cheers,
Alex
^ permalink raw reply [flat|nested] 22+ messages in thread
* Hardening
2015-12-25 15:38 ` Alex Vong
@ 2015-12-30 16:06 ` Ludovic Courtès
2016-08-16 23:57 ` Hardening Leo Famulari
0 siblings, 1 reply; 22+ messages in thread
From: Ludovic Courtès @ 2015-12-30 16:06 UTC (permalink / raw)
To: Alex Vong; +Cc: guix-devel
Alex Vong <alexvong1995@gmail.com> skribis:
> ludo@gnu.org (Ludovic Courtès) writes:
[...]
>> Alex Vong <alexvong1995@gmail.com> skribis:
>>
>>> From 6ad35e245c374ff828f167bb3467ce68559ccefd Mon Sep 17 00:00:00 2001
>>> From: Alex Vong <alexvong1995@gmail.com>
>>> Date: Sat, 31 Oct 2015 19:44:13 +0800
>>> Subject: [PATCH 1/2] Add (guix build build-flags).
>>>
>>> A module to manipulate build flags, similar to dpkg-buildflags.
>>>
>>> * guix/build/build-flags.scm: New file.
>>> * Makefile.am (MODULES): Register it.
>>
>> [...]
>>
>>> +;;; Module to manipulate build flags, similar to dpkg-buildflags.
>>
>> It doesn’t really help to refer to dpkg-buildflags, at least for me. ;-)
>>
> Sure, I should have elaborated more on it. What I am looking for are
> ways to avoid repeating a lot of flags in different packages, something
> like `use this set of flags, please'. For example, in Debian, if you
> type
>
> $ dpkg-buildflags --get CFLAGS
>
> you get
>
> -g -O2 -fstack-protector-strong -Wformat -Werror=format-security
>
> which are thr default flags to be exported during package
> build. Moroever, maintainer can alter the default behaviour by setting
> DEB_BUILD_MAINT_OPTIONS. For example,
>
> $ DEB_BUILD_MAINT_OPTIONS=hardening=+all dpkg-buildflags --get CFLAGS
>
> will return
>
> -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security
I see.
My comment was more about the code itself, whose documentation should be
self-contained as much as possible.
[...]
>> I’ve been thinking we should experiment with these various options. The
>> way I’d do it now would be by running:
>>
>> ./configure x y z CPPFLAGS=-D_FORTIFY_SOURCE=2 CFLAGS=-fstack-protector
>>
>> This would be just automatically added to #:configure-flags in
>> gnu-build-system.scm.
>>
>> Of course, some packages would ignore them and others would break, but
>> that’s part of the game. It largely have to be approached on a
>> case-by-case basis.
>>
> Yes, I grep for `fstack-protector-strong' in the guix code base and no
> matches are found. It appears no packages are setting this flag
> currently. I think this flag (perhaps also a couple others) should be
> set by default since they help protect against buffer overflow
> <https://en.wikipedia.org/wiki/Buffer_overflow_protection>.
I definitely agree, that’s something I’ve been wanting to try out.
The question is more how. Do we change the default #:configure-flags
for ‘gnu-build-system’ to something like:
'("CPPFLAGS=-D_FORTIFY_SOURCE=2"
"CFLAGS=-O2 -g -fstack-protector-strong")
?
That sounds like a good starting point, but I expect that (1) one third
of the packages will fail to build, and (2) another third of the
packages will not get these flags, for instance because they pass their
own #:configure-flags.
IOW, it will take a whole rebuild to find out exactly what’s going on
and to fix any issues.
Would you like to start working on it? Then we could create a branch,
have Hydra build it, and incrementally fix things.
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Hardening
2015-12-30 16:06 ` Hardening Ludovic Courtès
@ 2016-08-16 23:57 ` Leo Famulari
2016-08-17 6:49 ` Hardening Ricardo Wurmus
2016-09-02 13:08 ` Hardening Ludovic Courtès
0 siblings, 2 replies; 22+ messages in thread
From: Leo Famulari @ 2016-08-16 23:57 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
On Wed, Dec 30, 2015 at 05:06:30PM +0100, Ludovic Courtès wrote:
> Alex Vong <alexvong1995@gmail.com> skribis:
> > Yes, I grep for `fstack-protector-strong' in the guix code base and no
> > matches are found. It appears no packages are setting this flag
> > currently. I think this flag (perhaps also a couple others) should be
> > set by default since they help protect against buffer overflow
> > <https://en.wikipedia.org/wiki/Buffer_overflow_protection>.
>
> I definitely agree, that’s something I’ve been wanting to try out.
>
> The question is more how. Do we change the default #:configure-flags
> for ‘gnu-build-system’ to something like:
>
> '("CPPFLAGS=-D_FORTIFY_SOURCE=2"
> "CFLAGS=-O2 -g -fstack-protector-strong")
>
> ?
>
> That sounds like a good starting point, but I expect that (1) one third
> of the packages will fail to build, and (2) another third of the
> packages will not get these flags, for instance because they pass their
> own #:configure-flags.
>
> IOW, it will take a whole rebuild to find out exactly what’s going on
> and to fix any issues.
>
> Would you like to start working on it? Then we could create a branch,
> have Hydra build it, and incrementally fix things.
We should pick this project back up. I was suprised to find we haven't
done anything like this after reading this recent blog post about Nix's
hardening effort:
https://blog.mayflower.de/5800-Hardening-Compiler-Flags-for-NixOS.html?utm_source=twitterfeed&utm_medium=twitter
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Hardening
2016-08-16 23:57 ` Hardening Leo Famulari
@ 2016-08-17 6:49 ` Ricardo Wurmus
2016-08-17 13:48 ` Hardening Alex Vong
2016-09-02 13:08 ` Hardening Ludovic Courtès
1 sibling, 1 reply; 22+ messages in thread
From: Ricardo Wurmus @ 2016-08-17 6:49 UTC (permalink / raw)
To: Leo Famulari; +Cc: guix-devel
Leo Famulari <leo@famulari.name> writes:
> On Wed, Dec 30, 2015 at 05:06:30PM +0100, Ludovic Courtès wrote:
>> Alex Vong <alexvong1995@gmail.com> skribis:
>> > Yes, I grep for `fstack-protector-strong' in the guix code base and no
>> > matches are found. It appears no packages are setting this flag
>> > currently. I think this flag (perhaps also a couple others) should be
>> > set by default since they help protect against buffer overflow
>> > <https://en.wikipedia.org/wiki/Buffer_overflow_protection>.
>>
>> I definitely agree, that’s something I’ve been wanting to try out.
>>
>> The question is more how. Do we change the default #:configure-flags
>> for ‘gnu-build-system’ to something like:
>>
>> '("CPPFLAGS=-D_FORTIFY_SOURCE=2"
>> "CFLAGS=-O2 -g -fstack-protector-strong")
>>
>> ?
>>
>> That sounds like a good starting point, but I expect that (1) one third
>> of the packages will fail to build, and (2) another third of the
>> packages will not get these flags, for instance because they pass their
>> own #:configure-flags.
>>
>> IOW, it will take a whole rebuild to find out exactly what’s going on
>> and to fix any issues.
>>
>> Would you like to start working on it? Then we could create a branch,
>> have Hydra build it, and incrementally fix things.
>
> We should pick this project back up. I was suprised to find we haven't
> done anything like this after reading this recent blog post about Nix's
> hardening effort:
>
> https://blog.mayflower.de/5800-Hardening-Compiler-Flags-for-NixOS.html?utm_source=twitterfeed&utm_medium=twitter
Are the above flags the only flags we’d like to play with? There’s no
harm in letting hydra rebuild the world with these flags on a separate
branch — provided that all build nodes are usable.
~~ Ricardo
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Hardening
2016-08-17 6:49 ` Hardening Ricardo Wurmus
@ 2016-08-17 13:48 ` Alex Vong
2016-08-17 20:28 ` Hardening ng0
0 siblings, 1 reply; 22+ messages in thread
From: Alex Vong @ 2016-08-17 13:48 UTC (permalink / raw)
To: Ricardo Wurmus; +Cc: guix-devel
Hi,
Wow, this was long time ago. I've forgot this completely.
Ricardo Wurmus <rekado@elephly.net> writes:
> Leo Famulari <leo@famulari.name> writes:
>
>> On Wed, Dec 30, 2015 at 05:06:30PM +0100, Ludovic Courtès wrote:
>>> Alex Vong <alexvong1995@gmail.com> skribis:
>>> > Yes, I grep for `fstack-protector-strong' in the guix code base and no
>>> > matches are found. It appears no packages are setting this flag
>>> > currently. I think this flag (perhaps also a couple others) should be
>>> > set by default since they help protect against buffer overflow
>>> > <https://en.wikipedia.org/wiki/Buffer_overflow_protection>.
>>>
>>> I definitely agree, that’s something I’ve been wanting to try out.
>>>
>>> The question is more how. Do we change the default #:configure-flags
>>> for ‘gnu-build-system’ to something like:
>>>
>>> '("CPPFLAGS=-D_FORTIFY_SOURCE=2"
>>> "CFLAGS=-O2 -g -fstack-protector-strong")
>>>
>>> ?
>>>
>>> That sounds like a good starting point, but I expect that (1) one third
>>> of the packages will fail to build, and (2) another third of the
>>> packages will not get these flags, for instance because they pass their
>>> own #:configure-flags.
>>>
>>> IOW, it will take a whole rebuild to find out exactly what’s going on
>>> and to fix any issues.
>>>
>>> Would you like to start working on it? Then we could create a branch,
>>> have Hydra build it, and incrementally fix things.
>>
>> We should pick this project back up. I was suprised to find we haven't
>> done anything like this after reading this recent blog post about Nix's
>> hardening effort:
>>
>> https://blog.mayflower.de/5800-Hardening-Compiler-Flags-for-NixOS.html?utm_source=twitterfeed&utm_medium=twitter
>
> Are the above flags the only flags we’d like to play with? There’s no
> harm in letting hydra rebuild the world with these flags on a separate
> branch — provided that all build nodes are usable.
>
There are indeed additional flags (for debian's hardening).
Here is the complete output (from the testing distribution):
alexvong1995@debian:~$ DEB_BUILD_MAINT_OPTIONS=hardening=+all dpkg-buildflags
CFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security
CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2
CXXFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security
FCFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE -fstack-protector-strong
FFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE -fstack-protector-strong
GCJFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE -fstack-protector-strong
LDFLAGS=-fPIE -pie -Wl,-z,relro -Wl,-z,now
OBJCFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security
OBJCXXFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security
The `-fdebug-prefix-map' flag seems to be using the current working
directory.
> ~~ Ricardo
Cheers,
Alex
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Hardening
2016-08-17 13:48 ` Hardening Alex Vong
@ 2016-08-17 20:28 ` ng0
2016-08-19 9:30 ` Hardening ng0
2016-08-20 16:45 ` Hardening Alex Vong
0 siblings, 2 replies; 22+ messages in thread
From: ng0 @ 2016-08-17 20:28 UTC (permalink / raw)
To: Alex Vong, Ricardo Wurmus; +Cc: guix-devel
Alex Vong <alexvong1995@gmail.com> writes:
> Hi,
>
> Wow, this was long time ago. I've forgot this completely.
>
> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Leo Famulari <leo@famulari.name> writes:
>>
>>> On Wed, Dec 30, 2015 at 05:06:30PM +0100, Ludovic Courtès wrote:
>>>> Alex Vong <alexvong1995@gmail.com> skribis:
>>>> > Yes, I grep for `fstack-protector-strong' in the guix code base and no
>>>> > matches are found. It appears no packages are setting this flag
>>>> > currently. I think this flag (perhaps also a couple others) should be
>>>> > set by default since they help protect against buffer overflow
>>>> > <https://en.wikipedia.org/wiki/Buffer_overflow_protection>.
>>>>
>>>> I definitely agree, that’s something I’ve been wanting to try out.
>>>>
>>>> The question is more how. Do we change the default #:configure-flags
>>>> for ‘gnu-build-system’ to something like:
>>>>
>>>> '("CPPFLAGS=-D_FORTIFY_SOURCE=2"
>>>> "CFLAGS=-O2 -g -fstack-protector-strong")
>>>>
>>>> ?
>>>>
>>>> That sounds like a good starting point, but I expect that (1) one third
>>>> of the packages will fail to build, and (2) another third of the
>>>> packages will not get these flags, for instance because they pass their
>>>> own #:configure-flags.
>>>>
>>>> IOW, it will take a whole rebuild to find out exactly what’s going on
>>>> and to fix any issues.
>>>>
>>>> Would you like to start working on it? Then we could create a branch,
>>>> have Hydra build it, and incrementally fix things.
>>>
>>> We should pick this project back up. I was suprised to find we haven't
>>> done anything like this after reading this recent blog post about Nix's
>>> hardening effort:
>>>
>>> https://blog.mayflower.de/5800-Hardening-Compiler-Flags-for-NixOS.html?utm_source=twitterfeed&utm_medium=twitter
>>
>> Are the above flags the only flags we’d like to play with? There’s no
>> harm in letting hydra rebuild the world with these flags on a separate
>> branch — provided that all build nodes are usable.
>>
> There are indeed additional flags (for debian's hardening).
>
>
> Here is the complete output (from the testing distribution):
>
> alexvong1995@debian:~$ DEB_BUILD_MAINT_OPTIONS=hardening=+all dpkg-buildflags
> CFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security
> CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2
> CXXFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security
> FCFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE -fstack-protector-strong
> FFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE -fstack-protector-strong
> GCJFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE -fstack-protector-strong
> LDFLAGS=-fPIE -pie -Wl,-z,relro -Wl,-z,now
> OBJCFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security
> OBJCXXFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security
>
>
> The `-fdebug-prefix-map' flag seems to be using the current working
> directory.
>
>> ~~ Ricardo
>
> Cheers,
> Alex
>
I think there's even more, I can add to this thread when I have access
to my hardened vm systems again.
Good to see that this is being picked up again.
--
ng0
For non-prism friendly talk find me on http://www.psyced.org
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Hardening
2016-08-17 20:28 ` Hardening ng0
@ 2016-08-19 9:30 ` ng0
2016-08-20 16:45 ` Hardening Alex Vong
1 sibling, 0 replies; 22+ messages in thread
From: ng0 @ 2016-08-19 9:30 UTC (permalink / raw)
To: Alex Vong, Ricardo Wurmus; +Cc: guix-devel
ng0 <ng0@we.make.ritual.n0.is> writes:
> Alex Vong <alexvong1995@gmail.com> writes:
>
>> Hi,
>>
>> Wow, this was long time ago. I've forgot this completely.
>>
>> Ricardo Wurmus <rekado@elephly.net> writes:
>>
>>> Leo Famulari <leo@famulari.name> writes:
>>>
>>>> On Wed, Dec 30, 2015 at 05:06:30PM +0100, Ludovic Courtès wrote:
>>>>> Alex Vong <alexvong1995@gmail.com> skribis:
>>>>> > Yes, I grep for `fstack-protector-strong' in the guix code base and no
>>>>> > matches are found. It appears no packages are setting this flag
>>>>> > currently. I think this flag (perhaps also a couple others) should be
>>>>> > set by default since they help protect against buffer overflow
>>>>> > <https://en.wikipedia.org/wiki/Buffer_overflow_protection>.
>>>>>
>>>>> I definitely agree, that’s something I’ve been wanting to try out.
>>>>>
>>>>> The question is more how. Do we change the default #:configure-flags
>>>>> for ‘gnu-build-system’ to something like:
>>>>>
>>>>> '("CPPFLAGS=-D_FORTIFY_SOURCE=2"
>>>>> "CFLAGS=-O2 -g -fstack-protector-strong")
>>>>>
>>>>> ?
>>>>>
>>>>> That sounds like a good starting point, but I expect that (1) one third
>>>>> of the packages will fail to build, and (2) another third of the
>>>>> packages will not get these flags, for instance because they pass their
>>>>> own #:configure-flags.
>>>>>
>>>>> IOW, it will take a whole rebuild to find out exactly what’s going on
>>>>> and to fix any issues.
>>>>>
>>>>> Would you like to start working on it? Then we could create a branch,
>>>>> have Hydra build it, and incrementally fix things.
>>>>
>>>> We should pick this project back up. I was suprised to find we haven't
>>>> done anything like this after reading this recent blog post about Nix's
>>>> hardening effort:
>>>>
>>>> https://blog.mayflower.de/5800-Hardening-Compiler-Flags-for-NixOS.html?utm_source=twitterfeed&utm_medium=twitter
>>>
>>> Are the above flags the only flags we’d like to play with? There’s no
>>> harm in letting hydra rebuild the world with these flags on a separate
>>> branch — provided that all build nodes are usable.
>>>
>> There are indeed additional flags (for debian's hardening).
>>
>>
>> Here is the complete output (from the testing distribution):
>>
>> alexvong1995@debian:~$ DEB_BUILD_MAINT_OPTIONS=hardening=+all dpkg-buildflags
>> CFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security
>> CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2
>> CXXFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security
>> FCFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE -fstack-protector-strong
>> FFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE -fstack-protector-strong
>> GCJFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE -fstack-protector-strong
>> LDFLAGS=-fPIE -pie -Wl,-z,relro -Wl,-z,now
>> OBJCFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security
>> OBJCXXFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security
>>
>>
>> The `-fdebug-prefix-map' flag seems to be using the current working
>> directory.
>>
>>> ~~ Ricardo
>>
>> Cheers,
>> Alex
>>
>
> I think there's even more, I can add to this thread when I have access
> to my hardened vm systems again.
I mean there is more, but it depends on what we want. What I can share
is in the direction of Gentoo Hardened
( https://wiki.gentoo.org/wiki/Project:Hardened ,
https://wiki.gentoo.org/wiki/Project:Hardened/PaX_Quickstart )
and there are repos at https://gitweb.gentoo.org of the hardened project
showing the depths you can go to. Depending on what you will apply,
certain applications become difficult to compile but with patches
applied they succeed. Runtime gets difficult once you apply on top of a
PaX enabled kernel with GRSec the addtional useful things like paxctl-ng
for XATTR_PAX markings.
Gentoo hardened has not stabilized the gcc we use and use some other
version as stable, gcc-6 is testing in gentoo if I remember correctly.
If desired, I can setup a hardened gentoo again (my VM is currently
busy) and look at what their patches do in practice.
> Good to see that this is being picked up again.
--
ng0
For non-prism friendly talk find me on http://www.psyced.org
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Hardening
2016-08-17 20:28 ` Hardening ng0
2016-08-19 9:30 ` Hardening ng0
@ 2016-08-20 16:45 ` Alex Vong
1 sibling, 0 replies; 22+ messages in thread
From: Alex Vong @ 2016-08-20 16:45 UTC (permalink / raw)
To: ng0; +Cc: guix-devel
ng0 <ng0@we.make.ritual.n0.is> writes:
> Alex Vong <alexvong1995@gmail.com> writes:
>
>> Hi,
>>
>> Wow, this was long time ago. I've forgot this completely.
>>
>> Ricardo Wurmus <rekado@elephly.net> writes:
>>
>>> Leo Famulari <leo@famulari.name> writes:
>>>
>>>> On Wed, Dec 30, 2015 at 05:06:30PM +0100, Ludovic Courtès wrote:
>>>>> Alex Vong <alexvong1995@gmail.com> skribis:
>>>>> > Yes, I grep for `fstack-protector-strong' in the guix code base and no
>>>>> > matches are found. It appears no packages are setting this flag
>>>>> > currently. I think this flag (perhaps also a couple others) should be
>>>>> > set by default since they help protect against buffer overflow
>>>>> > <https://en.wikipedia.org/wiki/Buffer_overflow_protection>.
>>>>>
>>>>> I definitely agree, that’s something I’ve been wanting to try out.
>>>>>
>>>>> The question is more how. Do we change the default #:configure-flags
>>>>> for ‘gnu-build-system’ to something like:
>>>>>
>>>>> '("CPPFLAGS=-D_FORTIFY_SOURCE=2"
>>>>> "CFLAGS=-O2 -g -fstack-protector-strong")
>>>>>
>>>>> ?
>>>>>
>>>>> That sounds like a good starting point, but I expect that (1) one third
>>>>> of the packages will fail to build, and (2) another third of the
>>>>> packages will not get these flags, for instance because they pass their
>>>>> own #:configure-flags.
>>>>>
>>>>> IOW, it will take a whole rebuild to find out exactly what’s going on
>>>>> and to fix any issues.
>>>>>
>>>>> Would you like to start working on it? Then we could create a branch,
>>>>> have Hydra build it, and incrementally fix things.
>>>>
>>>> We should pick this project back up. I was suprised to find we haven't
>>>> done anything like this after reading this recent blog post about Nix's
>>>> hardening effort:
>>>>
>>>> https://blog.mayflower.de/5800-Hardening-Compiler-Flags-for-NixOS.html?utm_source=twitterfeed&utm_medium=twitter
>>>
>>> Are the above flags the only flags we’d like to play with? There’s no
>>> harm in letting hydra rebuild the world with these flags on a separate
>>> branch — provided that all build nodes are usable.
>>>
>> There are indeed additional flags (for debian's hardening).
>>
>>
>> Here is the complete output (from the testing distribution):
>>
>> alexvong1995@debian:~$ DEB_BUILD_MAINT_OPTIONS=hardening=+all dpkg-buildflags
>> CFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE
>> -fstack-protector-strong -Wformat -Werror=format-security
>> CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2
>> CXXFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE
>> -fstack-protector-strong -Wformat -Werror=format-security
>> FCFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE
>> -fstack-protector-strong
>> FFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE
>> -fstack-protector-strong
>> GCJFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE
>> -fstack-protector-strong
>> LDFLAGS=-fPIE -pie -Wl,-z,relro -Wl,-z,now
>> OBJCFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE
>> -fstack-protector-strong -Wformat -Werror=format-security
>> OBJCXXFLAGS=-g -O2 -fdebug-prefix-map=/home/alexvong1995=. -fPIE
>> -fstack-protector-strong -Wformat -Werror=format-security
>>
>>
>> The `-fdebug-prefix-map' flag seems to be using the current working
>> directory.
>>
>>> ~~ Ricardo
>>
>> Cheers,
>> Alex
>>
>
> I think there's even more, I can add to this thread when I have access
> to my hardened vm systems again.
>
Yes, I think people running guix on top of another distro can tell how
their distro do the hardening, so we can see what are the existing
practices.
> Good to see that this is being picked up again.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Hardening
2016-08-16 23:57 ` Hardening Leo Famulari
2016-08-17 6:49 ` Hardening Ricardo Wurmus
@ 2016-09-02 13:08 ` Ludovic Courtès
2016-09-03 11:34 ` Hardening ng0
1 sibling, 1 reply; 22+ messages in thread
From: Ludovic Courtès @ 2016-09-02 13:08 UTC (permalink / raw)
To: Leo Famulari; +Cc: guix-devel
Leo Famulari <leo@famulari.name> skribis:
> On Wed, Dec 30, 2015 at 05:06:30PM +0100, Ludovic Courtès wrote:
>> Alex Vong <alexvong1995@gmail.com> skribis:
>> > Yes, I grep for `fstack-protector-strong' in the guix code base and no
>> > matches are found. It appears no packages are setting this flag
>> > currently. I think this flag (perhaps also a couple others) should be
>> > set by default since they help protect against buffer overflow
>> > <https://en.wikipedia.org/wiki/Buffer_overflow_protection>.
>>
>> I definitely agree, that’s something I’ve been wanting to try out.
>>
>> The question is more how. Do we change the default #:configure-flags
>> for ‘gnu-build-system’ to something like:
>>
>> '("CPPFLAGS=-D_FORTIFY_SOURCE=2"
>> "CFLAGS=-O2 -g -fstack-protector-strong")
>>
>> ?
>>
>> That sounds like a good starting point, but I expect that (1) one third
>> of the packages will fail to build, and (2) another third of the
>> packages will not get these flags, for instance because they pass their
>> own #:configure-flags.
>>
>> IOW, it will take a whole rebuild to find out exactly what’s going on
>> and to fix any issues.
>>
>> Would you like to start working on it? Then we could create a branch,
>> have Hydra build it, and incrementally fix things.
>
> We should pick this project back up. I was suprised to find we haven't
> done anything like this after reading this recent blog post about Nix's
> hardening effort:
>
> https://blog.mayflower.de/5800-Hardening-Compiler-Flags-for-NixOS.html?utm_source=twitterfeed&utm_medium=twitter
Definitely! As discussed on IRC, an option would be to add a keyword
parameter to ‘gnu-build-system’:
#:hardening-flags '(fortify stack-protector)
Then ‘configure’ in (guix build gnu-build-system) would translate that
into CPPFLAGS and CFLAGS options for ‘configure’, as shown above.
The main difficulty with this is that many packages will break. Thus,
if we make it opt-out, we’ll have to fix packages one by one. It seems
unavoidable though.
Thoughts?
Ludo’.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Hardening
2016-09-02 13:08 ` Hardening Ludovic Courtès
@ 2016-09-03 11:34 ` ng0
0 siblings, 0 replies; 22+ messages in thread
From: ng0 @ 2016-09-03 11:34 UTC (permalink / raw)
To: Ludovic Courtès, Leo Famulari; +Cc: guix-devel
Ludovic Courtès <ludo@gnu.org> writes:
> Leo Famulari <leo@famulari.name> skribis:
>
>> On Wed, Dec 30, 2015 at 05:06:30PM +0100, Ludovic Courtès wrote:
>>> Alex Vong <alexvong1995@gmail.com> skribis:
>>> > Yes, I grep for `fstack-protector-strong' in the guix code base and no
>>> > matches are found. It appears no packages are setting this flag
>>> > currently. I think this flag (perhaps also a couple others) should be
>>> > set by default since they help protect against buffer overflow
>>> > <https://en.wikipedia.org/wiki/Buffer_overflow_protection>.
>>>
>>> I definitely agree, that’s something I’ve been wanting to try out.
>>>
>>> The question is more how. Do we change the default #:configure-flags
>>> for ‘gnu-build-system’ to something like:
>>>
>>> '("CPPFLAGS=-D_FORTIFY_SOURCE=2"
>>> "CFLAGS=-O2 -g -fstack-protector-strong")
>>>
>>> ?
>>>
>>> That sounds like a good starting point, but I expect that (1) one third
>>> of the packages will fail to build, and (2) another third of the
>>> packages will not get these flags, for instance because they pass their
>>> own #:configure-flags.
>>>
>>> IOW, it will take a whole rebuild to find out exactly what’s going on
>>> and to fix any issues.
>>>
>>> Would you like to start working on it? Then we could create a branch,
>>> have Hydra build it, and incrementally fix things.
>>
>> We should pick this project back up. I was suprised to find we haven't
>> done anything like this after reading this recent blog post about Nix's
>> hardening effort:
>>
>> https://blog.mayflower.de/5800-Hardening-Compiler-Flags-for-NixOS.html?utm_source=twitterfeed&utm_medium=twitter
>
> Definitely! As discussed on IRC, an option would be to add a keyword
> parameter to ‘gnu-build-system’:
>
> #:hardening-flags '(fortify stack-protector)
>
> Then ‘configure’ in (guix build gnu-build-system) would translate that
> into CPPFLAGS and CFLAGS options for ‘configure’, as shown above.
>
> The main difficulty with this is that many packages will break. Thus,
> if we make it opt-out, we’ll have to fix packages one by one. It seems
> unavoidable though.
That's how everyone does it, enable per package or globally, test, apply
system-specific patches. Unavoidable but it works. I think we could
create a branch, let's call it 'hardening', globally harden everything
and see how much fails and how, look at how debian, gentoo, *bsd solve
the hardening fails and fix it for every individual packages.
> Thoughts?
>
> Ludo’.
>
--
ng0
For non-prism friendly talk find me on http://www.psyced.org
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2018-03-22 13:16 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-01-29 12:44 hardening ng0
2018-01-29 19:21 ` hardening Joshua Branson
2018-01-29 20:55 ` hardening ng0
2018-01-31 12:20 ` hardening Alex Vong
2018-03-11 13:37 ` hardening ng0
2018-03-11 13:40 ` hardening ng0
2018-03-11 14:04 ` hardening Ricardo Wurmus
2018-03-11 14:36 ` hardening ng0
2018-03-22 13:16 ` hardening ng0
-- strict thread matches above, loose matches on Subject: below --
2017-01-24 11:19 tor: update to 0.2.9.9 contact.ng0
2017-01-24 19:07 ` Leo Famulari
2017-01-24 20:56 ` Hardening (was: Re: tor: update to 0.2.9.9) ng0
2017-01-24 21:02 ` Leo Famulari
2017-01-24 21:09 ` ng0
2017-01-24 21:18 ` ng0
2017-01-24 21:32 ` Leo Famulari
2017-01-24 21:56 ` ng0
2017-01-25 13:04 ` Hardening Ludovic Courtès
2017-01-30 12:05 ` Hardening ng0
2017-01-30 12:16 ` Hardening ng0
2017-01-25 9:09 ` Hardening (was: Re: tor: update to 0.2.9.9) Ricardo Wurmus
2017-01-25 11:51 ` Hardening ng0
2015-10-31 13:56 [PATCH 1/2] Add (guix build build-flags) Alex Vong
2015-11-05 21:55 ` Ludovic Courtès
2015-12-25 15:38 ` Alex Vong
2015-12-30 16:06 ` Hardening Ludovic Courtès
2016-08-16 23:57 ` Hardening Leo Famulari
2016-08-17 6:49 ` Hardening Ricardo Wurmus
2016-08-17 13:48 ` Hardening Alex Vong
2016-08-17 20:28 ` Hardening ng0
2016-08-19 9:30 ` Hardening ng0
2016-08-20 16:45 ` Hardening Alex Vong
2016-09-02 13:08 ` Hardening Ludovic Courtès
2016-09-03 11:34 ` Hardening ng0
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).