binutils as policy checker (was: RFC: Add a linker warning when creating segments with RWX permissions)

[Joel Sherrill]

On Tue, Apr 26, 2022 at 10:07 AM Michael Matz via Binutils <
binutils@sourceware.org> wrote:

> Hello,
>
> On Tue, 26 Apr 2022, Nick Clifton via Binutils wrote:
>
> >   Following on from the patch to add warnings when the linker creates an
> >   executable stack, here is another proposal for a patch to add a
> >   warning when the linker creates a memory resident segment with RWX
> >   permissions.
>
> Is binutils really the right place to enforce policies?  I'm
> slightly worried about this direction.
>
> I consider all these kinds of checks, which do have some sense, to be
> implementing a certain set of rules that aren't inherent in the design or
> requirements of binary files intended to hold object code and data, i.e. a
> policy.  And for checking adherence to a policy I would expect a policy
> checker tool to be more appropriate than tools designed for creating such
> object files.  Not in the least because policies can sometimes change
> quite quickly (and arbitrarily) and hence need quickly adjustable tooling
> anyway and (even more so) that policies are different for different
> audiences and so encoding one specific policy into a tool looks wrong.
>
> E.g. here I would expect a post-build checker tool to test for RWX
> segments in generated ELF files, like rpmlint and friends, as the distros
> are using already, of course, because that's what the distro makers
> decided to be a policy, not because the binutils authors decided so (I'm
> aware that there's a large overlap in those two sets of people :) ).
>

RTEMS can run paravirtualized in an ARINC 653 RTOS for avionics
applications.
That RTOS has a utility to check executables like you suggest.

I also found this Ubuntu man page online which appears to be along
the lines you are suggesting:

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

Those look like generic checks which might apply to any gcc/binutils
target environment but, as you state, it is the distribution that sets the
policy set.

Maybe something that can make the checks but be tailorable. At least
the source for the checks would be shared then and a wrapper script
could enforce the policy.

Just thinking out loud.

--joel


>
>
> Ciao,
> Michael.
>