From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CD9E7C67839 for ; Thu, 13 Dec 2018 05:13:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9E8A620672 for ; Thu, 13 Dec 2018 05:13:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9E8A620672 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-security-module-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726618AbeLMFNr (ORCPT ); Thu, 13 Dec 2018 00:13:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49638 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726593AbeLMFNr (ORCPT ); Thu, 13 Dec 2018 00:13:47 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0D00E307D843; Thu, 13 Dec 2018 05:13:46 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-116-82.ams2.redhat.com [10.36.116.82]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D2CB05D717; Thu, 13 Dec 2018 05:13:40 +0000 (UTC) From: Florian Weimer To: James Morris Cc: =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= , linux-kernel@vger.kernel.org, Al Viro , Jonathan Corbet , Kees Cook , Matthew Garrett , Michael Kerrisk , =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= , Mimi Zohar , Philippe =?utf-8?Q?Tr=C3=A9buchet?= , Shuah Khan , Thibaut Sautereau , Vincent Strubel , Yves-Alexis Perez , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [RFC PATCH v1 0/5] Add support for O_MAYEXEC References: <20181212081712.32347-1-mic@digikod.net> <87lg4upkpv.fsf@oldenburg2.str.redhat.com> Date: Thu, 13 Dec 2018 06:13:39 +0100 In-Reply-To: (James Morris's message of "Thu, 13 Dec 2018 10:40:32 +1100 (AEDT)") Message-ID: <87ftv2ovp8.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.48]); Thu, 13 Dec 2018 05:13:47 +0000 (UTC) Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: * James Morris: > On Wed, 12 Dec 2018, Florian Weimer wrote: > >> * James Morris: >> >> > If you're depending on the script interpreter to flag that the user may >> > execute code, this seems to be equivalent in security terms to depending >> > on the user. e.g. what if the user uses ptrace and clears O_MAYEXEC? >> >> The argument I've heard is this: Using ptrace (and adding the +x >> attribute) are auditable events. > > I guess you could also preload a modified libc which strips the flag. My understanding is that this new libc would have to come somewhere, and making it executable would be an auditable even as well. Thanks, Florian