Meson: No easy way to enable full RELRO on security sensitive binaries

[hughsie]

It seems meson defaults to "partial RELRO" + PIE for executables which seems a good default. For security sensitive things we need to have "full RELRO" which is more secure, but does have a small runtime cost. Full RELRO is usually set for daemons running as root or things that are taking untrusted binary things from the Internet. More info here: http://tk-blog.blogspot.co.uk/2009/02/relro-not-so-well-known-memory.html

I know you can do this for all exectuables using something like https://github.com/GNOME/sysprof/blob/52bc856be44e52480eb91dca922abf4444e30ac4/meson.build#L62-L65 but it makes sense to me to have some kind of executable() argument to specify the security level. Either something as low level as relro : "full" or something high level like hardening: "full" would be fine, the latter could also enable a different set of stack protection options too.

Thanks again.

[hughsie]

As @TingPing pointed out, the penalty for "full RELRO" isn't huge for most binaries so perhaps we could just change the project defaults allowing projects that really need that fast startup time over the (pretty large) security benefits could opt-out.

[nirbheek]

The only question I have is whether there are equivalents for other platforms: OS X and Windows that we should enable when that option is turned on. Otherwise it'll be misleading for people if it's a no-op on other platforms. If there's no equivalents, we can give it a linux-specific name that makes it clear that it is only available on Linux.

[TingPing]

For stack protector (wikipedia):

The compiler suite from Microsoft implements buffer overflow protection since version 2003 through the /GS command-line switch, which is enabled by default since version 2005.[30] Using /GS- disables the protection.

[jpakkane]

Otherwise it'll be misleading for people if it's a no-op on other platforms. If there's no equivalents, we can give it a linux-specific name that makes it clear that it is only available on Linux.

We already do this. For example lundef is not available on OSX so we don't add that to the list of options when compiling to it. Similarly asan is only available on GCC + Clang, not MSVC, etc.

[nirbheek]

Ah, it makes sense as a build argument true. Perhaps we can even default to it. My comment was only for kwargs.

[hughsie]

This has caused problems in RHEL where applications porting from automake to meson are not being built with full RELRO, which causes them to fail the automated security tests Red Hat does. I guess one workaround is to copy around the fwupd "workaround" https://github.com/hughsie/fwupd/blob/master/meson.build#L108 to all projects although this is kind of nasty. I'm not sure I understand mesons codebase enough to attempt something like executable(hardening: "full") but with enough pointers I could give it a go.

[QuLogic]

RedHat packages? They should be setting buildtype=plain and then grabbing the relevant flags from CC, etc., like Fedora does. This is automatic without having to mess with meson.build.

[nirbheek]

buildtype=plain is indeed the solution for now. We can add support for this to Meson, but it should be as a builtin-option not a kwarg on a target. It can be alongside the new optimization builtin-option.

[QuLogic]

Well, what I mean is, if we're trying to satisfy packaging requirements, they should be satisfied by fixing the package in preference to messing with the meson.build. Whether meson wants to add a flag or not is orthogonal, but enabling full RELRO is achievable with existing settings and is already done for any meson-using package in Fedora, so the same should be possible in RHEL.

[pwnorbitals]

As this issue is old, has a workaround and proably isn’t up-to-date with the latest developments, I suggest we can close it now

[hughsie]

and then grabbing the relevant flags from CC

Well, that works when building packages in something that's setting the CC flags, but for a developer on a workstation they're going to be blank... which is why I thought we should provide some kind of toggle to enable/disable it.

[dcbaker]

I think we should have a toggle for this. Different compilers have different options for this, and having a generic way to turn this kind of stuff on from the command line is very mesonic.