public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Joel Sherrill <joel@rtems.org>
To: Michael Matz <matz@suse.de>
Cc: Nick Clifton <nickc@redhat.com>, binutils <binutils@sourceware.org>
Subject: Re: binutils as policy checker (was: RFC: Add a linker warning when creating segments with RWX permissions)
Date: Tue, 26 Apr 2022 10:20:31 -0500	[thread overview]
Message-ID: <CAF9ehCU37KnQdr_wQ7Pu-nDVF3JotUDFGQogfXMTqjwfAKUc+Q@mail.gmail.com> (raw)
In-Reply-To: <alpine.LSU.2.20.2204261452380.32194@wotan.suse.de>

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

  reply	other threads:[~2022-04-26 15:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-26 11:31 RFC: Add a linker warning when creating segments with RWX permissions Nick Clifton
2022-04-26 13:56 ` Jan Beulich
2022-04-26 16:39   ` Nick Clifton
2022-04-26 15:06 ` binutils as policy checker (was: RFC: Add a linker warning when creating segments with RWX permissions) Michael Matz
2022-04-26 15:20   ` Joel Sherrill [this message]
2022-04-28  9:46     ` Nick Clifton
2022-04-29  6:29       ` Sam James
2022-05-03 14:54       ` Michael Matz
2022-05-03 19:35       ` Matthias Klose
2022-05-03 19:57         ` H.J. Lu
2022-05-03 20:29           ` Matthias Klose
2022-04-26 16:47   ` Nick Clifton

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=CAF9ehCU37KnQdr_wQ7Pu-nDVF3JotUDFGQogfXMTqjwfAKUc+Q@mail.gmail.com \
    --to=joel@rtems.org \
    --cc=binutils@sourceware.org \
    --cc=matz@suse.de \
    --cc=nickc@redhat.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).