[PATCH 1/2] Add (guix build build-flags).

[PATCH 1/2] Add (guix build build-flags).

[Alex Vong]

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

Re: [PATCH 1/2] Add (guix build build-flags).

[Ludovic Courtès]

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

Re: [PATCH 1/2] Add (guix build build-flags).

[Alex Vong]

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

Hardening

[Ludovic Courtès]

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

Re: Hardening

[Leo Famulari]

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

Re: Hardening

[Ricardo Wurmus]

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

Re: Hardening

[Alex Vong]

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

Re: Hardening

[ng0]

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

Re: Hardening

[ng0]

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

Re: Hardening

[Alex Vong]

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.

Re: Hardening

[Ludovic Courtès]

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

Re: Hardening

[ng0]

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

tor: update to 0.2.9.9

[contact.ng0]

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.

Re: tor: update to 0.2.9.9

[Leo Famulari]

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

Hardening (was: Re: tor: update to 0.2.9.9)

[ng0]

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/

Re: Hardening (was: Re: tor: update to 0.2.9.9)

[Leo Famulari]

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.

Re: Hardening (was: Re: tor: update to 0.2.9.9)

[ng0]

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/

Re: Hardening (was: Re: tor: update to 0.2.9.9)

[ng0]

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/

Re: Hardening (was: Re: tor: update to 0.2.9.9)

[Leo Famulari]

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.

Re: Hardening (was: Re: tor: update to 0.2.9.9)

[ng0]

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/

Re: Hardening

[Ludovic Courtès]

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

Re: Hardening

[ng0]

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/

Re: Hardening

[ng0]

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/

Re: Hardening (was: Re: tor: update to 0.2.9.9)

[Ricardo Wurmus]

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

Re: Hardening

[ng0]

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/

hardening

[ng0]

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/

Re: hardening

[Joshua Branson]

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

Re: hardening

[ng0]

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/

Re: hardening

[Alex Vong]

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

Re: hardening

[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

Re: hardening

[ng0]

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

Re: hardening

[Ricardo Wurmus]

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

Re: hardening

[ng0]

Ricardo Wurmus transcribed 486 bytes:
> 
> 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.

Well there's the Debian wiki: https://wiki.debian.org/Hardening
and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=643632 as well
as the gcc Manual about it. Debian uses -D_FORTIFY_SOURCE -O1.
My use of -O2 -D_FORTIFY_SOURCE in CFLAGS was not correct.

> 
> --
> Ricardo
> 
> 
> 

-- 
A88C8ADD129828D7EAC02E52E22F9BBFEE348588
https://n0.is

Re: hardening

[ng0]

Let's keep this thread as the thread to discuss possible solutions and work
in that field.

Yesterday Marius wrote on IRC (https://gnunet.org/bot/log/guix/2018-03-21#T1657250):

[        ]	<mbakke>	This is a pretty good article about build flags (mainly hardening related): https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-...
[        ]	<mbakke>	It would be great to have a "#:hardening?" option with additional provisions for specific flags.

The link in full: https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/

Nix has an a functionality to disable hardening:
https://github.com/NixOS/nixpkgs/search?utf8=%E2%9C%93&q=harden&type=
for example visible here: https://github.com/NixOS/nixpkgs/commit/f5b04628f00e98e4c757466ab6be2c125d89feeb

I have some more notes on Gentoo I'll add next month.

Food for thought:
If we go all in, we might have to recompile the bootstrap binaries.


keyword #:hardening-flags is a good entry for manually fixing packages up to
the point where they work with hardened flags. Caveat is, not everything will
work good or even at all with hardened-flags and toolchain.
So we are presented with 2 options.
1) Selectively harden what is possible through the keyword mentioned above
or
2) harden by default and switch off flags through something like #:hardening-exclude
   which would default to the empty list and otherwise would remove the elements in its
   list from the list of flags.

Further thoughts:
#:hardened? could be a simple check so that having package-graphs which are not hardened
are possible. We would default to #t, off would be #f obviously.


My work in progress so far is to work this into the gnu-build-system, which seemed like
a good starting point.

I'm in favor of option 2 coupled with the keyword to disable hardening altogether.

WDYT?
-- 
A88C8ADD129828D7EAC02E52E22F9BBFEE348588
https://n0.is