All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.