From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) by sourceware.org (Postfix) with ESMTPS id 72FAC3857823 for ; Tue, 26 Apr 2022 15:20:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 72FAC3857823 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rtems.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oi1-f179.google.com with SMTP id l203so10167055oif.0 for ; Tue, 26 Apr 2022 08:20:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=O4ers3Ml/3PYTZBdCUfkAiuf65NMUhakMGj2LFc48zk=; b=kfOHflTBeW9XgpVMm3fF7A2Jzq7gIHulonpgl/tqayNYJP158Y8XY9xZoGhOFXnN03 GkaulSWI1nreDgOpSYmNY9rgAEeXUsllXWnu1/IzEYYZczQPvzEGLHId94syt21yEtkR 41k0QUraZt/T4ek1PPQt5Zz4JsDsm7RS/rLwppBoYGbWXp18uMzKCLUze6XgoLZeyuf0 zgUwOalxlQyzZbtd99IJUeaB9oZu8rjtOaGeT0CxykRBwiLdqg+fzqwyPfEI2MYjYhZr h2E7oxsFoRst6HonTxsVmXwKooEr9iDBoY3cpTOxLwxwZUkHSugNC+1dpMiVwzcpTB/H 031g== X-Gm-Message-State: AOAM532AmKtCwdbd59aUHlF02ZBYYczwta+YJ8tR5Lyv5NJQ4v2giPnd cDTfi2Xb5Q8Hao7YUm7lTfufyxXVG+Q= X-Google-Smtp-Source: ABdhPJzy7O+njSgYEcIA8wa+gtnwWlZT33hj0BBRRM33tDIdVXhKnZgGW/KlpTEn9nttGdDRQuya6A== X-Received: by 2002:a05:6808:2024:b0:323:57d:d03f with SMTP id q36-20020a056808202400b00323057dd03fmr10416111oiw.62.1650986443417; Tue, 26 Apr 2022 08:20:43 -0700 (PDT) Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com. [209.85.210.50]) by smtp.gmail.com with ESMTPSA id c2-20020a9d6c82000000b00605988f38c9sm4095313otr.21.2022.04.26.08.20.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 Apr 2022 08:20:43 -0700 (PDT) Received: by mail-ot1-f50.google.com with SMTP id t6-20020a056830224600b00605491a5cd7so13241048otd.13 for ; Tue, 26 Apr 2022 08:20:43 -0700 (PDT) X-Received: by 2002:a05:6830:1551:b0:605:4fec:cfc7 with SMTP id l17-20020a056830155100b006054feccfc7mr8416881otp.295.1650986442848; Tue, 26 Apr 2022 08:20:42 -0700 (PDT) MIME-Version: 1.0 References: <878rrsw074.fsf@redhat.com> In-Reply-To: Reply-To: joel@rtems.org From: Joel Sherrill Date: Tue, 26 Apr 2022 10:20:31 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: binutils as policy checker (was: RFC: Add a linker warning when creating segments with RWX permissions) To: Michael Matz Cc: Nick Clifton , binutils X-Spam-Status: No, score=-3031.7 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2022 15:20:46 -0000 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. >