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-
next prev 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.