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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox