Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Stefan Fröberg" <stefan.froberg@petroprogram.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2 2/2] security hardening: add RELFO, FORTIFY options
Date: Wed, 08 Nov 2017 04:01:11 +0200	[thread overview]
Message-ID: <5A026567.8070101@petroprogram.com> (raw)
In-Reply-To: <e29b21b0-6c5f-ef3b-4123-9e8782639f43@mind.be>



6.11.2017, 23:14, Arnout Vandecappelle kirjoitti:
> @@ -181,6 +184,28 @@ TARGET_CXXFLAGS += -fstack-protector-all
>   TARGET_FCFLAGS += -fstack-protector-all
>   endif
>   
> +ifeq ($(BR2_RELRO_PARTIAL),y)
> +TARGET_CFLAGS += $(TARGET_CFLAGS_RELRO)
> +TARGET_CXXFLAGS += $(TARGET_CFLAGS_RELRO)
> +TARGET_FCFLAGS += $(TARGET_CFLAGS_RELRO)
>   Since these are linker flags, it _should_ be sufficient to add them to LDFLAGS.
> There may be some packages that don't listen to LDFLAGS so in that sense it
> could be a good idea to add it to CFLAGS as well, but I tend to prefer to fix
> the packages. Only, there is no easy way to detect that LDFLAGS are ignored.
>

There could be a way to tell if package shows middle finger to 
CFLAGS/CXXFLAGS/LDFLAGS
and just ignores the hardening options.

There's a little perl script called hardening-check that could be used 
to do post installation checking
of what packages actually respected the flags.

http://manpages.ubuntu.com/manpages/trusty/man1/hardening-check.1.html

I have a copy of that perl script here:
https://www.orwell1984.today/hardening-check

I also did the following little test:
1. First compiled turbovnc against i686-uclibc without any hardening and 
then running
"hardening-check -c output/target/usr/bin/Xvnc" with following results:

output/target/usr/bin/Xvnc:
  Position Independent Executable: ^[no, normal executable!^[
  Stack protected: ^[no, not found!^[
  Fortify Source functions: ^[no, only unprotected functions found!^[
  Read-only relocations: ^[yes^[
  Immediate binding: ^[no, not found!^[

2. Then forced the gcc compiler to use hardening features by using GCC 
Spec File, so that
if turbovnc did ignore CFLAGS/CXXFLAGS/LDFLAGS it would still be 
forcefeed the right
hardening options, like this:

- Dump the built-in specs file "$(HOST_CC) -dumpspecs > specs" and then 
edit it
to enable all the hardening stuff
(here's mine for i686-uclibc, forgot to enable stack-protection: 
https://www.orwell1984.today/specs)

- Find location where gcc looks for specs file "dirname $($(HOST_CC)  
--print-libgcc-file-name)"
and move the edited specs file there

- Rebuild turbovnc

- And finally, check "hardening-check -c output/target/usr/bin/Xvnc" 
with following result:

output/target/usr/bin/Xvnc:
  Position Independent Executable: ^[yes^[
  Stack protected: ^[no, not found!^[
  Fortify Source functions: no, only unprotected functions found!^[
  Read-only relocations: ^[yes^[
  Immediate binding: ^[yes^[

Here turbovnc built with pie, relro,now and if I would have remember to 
enable stack protection in toolchain,
also with stack protection.

So that's a one way to force & check hardening afterwards. But have to 
admit, not very elegant way.

Maybe there could be hardened directory with some premade "profiles" 
(gcc spec files) for various arch-lib combos
which could be selected from menu and then the buildroot cross-compiler 
would have
it's `dirname $($HOST_CC) --print-libgcc-file-name`/specs be a just 
symlink to that arch-lib combos like this:

output/host/lib/gcc/i686-buildroot-linux-uclibc/6.4.0/specs --> 
../../../../../../hardened/i686/uclibc/specs

If selecting vanilla, non-hardened toolchain from menu, it would just 
remove the symlink.
And maybe there could be an option to run hardening-check script at the 
end of installation.

Just throwing thoughts around
-S-

  parent reply	other threads:[~2017-11-08  2:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-25 12:59 [Buildroot] [PATCH v2 1/2] stack protector: moved option out of adv menu Matt Weber
2017-10-25 12:59 ` [Buildroot] [PATCH v2 2/2] security hardening: add RELFO, FORTIFY options Matt Weber
2017-11-06 21:14   ` Arnout Vandecappelle
2017-11-07  0:08     ` Matthew Weber
2017-11-07  3:25       ` Matthew Weber
2017-11-07  9:08         ` Arnout Vandecappelle
2017-11-07 19:31           ` Waldemar Brodkorb
2017-11-07 20:42             ` Arnout Vandecappelle
2017-11-08  2:01     ` Stefan Fröberg [this message]
2017-11-11 10:42       ` Arnout Vandecappelle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5A026567.8070101@petroprogram.com \
    --to=stefan.froberg@petroprogram.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox