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=-6.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 7824CC2D0A8 for ; Wed, 23 Sep 2020 19:42:52 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EFE9E20BED for ; Wed, 23 Sep 2020 19:42:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="wdaFl0xb"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="kGXISa+f" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EFE9E20BED Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=XIbTV5o+LiqMBPQPEAHcGSXjKlAnbU7RE0dm4pTK0QQ=; b=wdaFl0xbz9GismCMQnYY9QlqX A6EVxsbu7nPcSZTJa9NtO1PtRQjbsavzcOGk1HpLgDyrpVsPT0+hq2dU0n1wXlqBGPyzdgxzqYy5i lZ8dINJY2nGuBKgJjM7vuoS71B3X5D1A2/MznYXQjEGy2MV+ZGYLmVLyn2Tn3guINzmEzkhP8a8/3 qaLWJ1R+ao1/rFsT5/1ZpoggNzXq5SpgXEgOOtPOGXh2lrn3szquULXip2zxrvWCiWdRVY8ymIMaY rBZhh+bmcEeV3Lo+WfOz00xE+AHqGJTW5tXk8h5yVIpYMPcfCvX+zpg11PzCBumtoYPGWZpgfzicI QLB6v4Z8A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kLAda-0007vE-Ih; Wed, 23 Sep 2020 19:41:10 +0000 Received: from linux.microsoft.com ([13.77.154.182]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kLAdX-0007u4-Sc for linux-arm-kernel@lists.infradead.org; Wed, 23 Sep 2020 19:41:09 +0000 Received: from [192.168.254.38] (unknown [47.187.206.220]) by linux.microsoft.com (Postfix) with ESMTPSA id 24DE220B7179; Wed, 23 Sep 2020 12:41:05 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 24DE220B7179 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1600890066; bh=SHLv6M19mTEA3Q+HMwGO2d17v134ff6kOkHWg2oExmk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=kGXISa+fmD0BCDpEQnnCH9Pq25TnzBLU7eNC7j4udIn/khcedGMZt32Iq7JAPGchg luAP/WHcUq9x1xW1/50YFmrTM0/nW5osVqFkqlgScNmlE+wnu2v0ZixY9PaCUGo0Y4 MRQIBAlfv+g5G8+XBslF45bPRw9XRky7bkjKl3Bc= Subject: Re: [PATCH v2 0/4] [RFC] Implement Trampoline File Descriptor To: Solar Designer , Pavel Machek References: <20200922215326.4603-1-madvenka@linux.microsoft.com> <20200923081426.GA30279@amd> <20200923091456.GA6177@openwall.com> From: "Madhavan T. Venkataraman" Message-ID: <1c3acf03-94af-1d5e-00c6-d874ee0ef330@linux.microsoft.com> Date: Wed, 23 Sep 2020 14:41:04 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200923091456.GA6177@openwall.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200923_154108_085587_521895EA X-CRM114-Status: GOOD ( 36.03 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: fweimer@redhat.com, mark.rutland@arm.com, Rich Felker , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, oleg@redhat.com, mic@digikod.net, linux-security-module@vger.kernel.org, David.Laight@ACULAB.COM, luto@kernel.org, linux-fsdevel@vger.kernel.org, linux-integrity@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 9/23/20 4:14 AM, Solar Designer wrote: >>> The W^X implementation today is not complete. There exist many user level >>> tricks that can be used to load and execute dynamic code. E.g., >>> >>> - Load the code into a file and map the file with R-X. >>> >>> - Load the code in an RW- page. Change the permissions to R--. Then, >>> change the permissions to R-X. >>> >>> - Load the code in an RW- page. Remap the page with R-X to get a separate >>> mapping to the same underlying physical page. >>> >>> IMO, these are all security holes as an attacker can exploit them to inject >>> his own code. >> IMO, you are smoking crack^H^H very seriously misunderstanding what >> W^X is supposed to protect from. >> >> W^X is not supposed to protect you from attackers that can already do >> system calls. So loading code into a file then mapping the file as R-X >> is in no way security hole in W^X. >> >> If you want to provide protection from attackers that _can_ do system >> calls, fine, but please don't talk about W^X and please specify what >> types of attacks you want to prevent and why that's good thing. > On one hand, Pavel is absolutely right. It is ridiculous to say that > "these are all security holes as an attacker can exploit them to inject > his own code." > Why? Isn't it possible that an attacker can exploit some vulnerability such as buffer overflow and overwrite the buffer that contains the dynamic code? > On the other hand, "what W^X is supposed to protect from" depends on how > the term W^X is defined (historically, by PaX and OpenBSD). It may be > that W^X is partially not a feature to defeat attacks per se, but also a > policy enforcement feature preventing use of dangerous techniques (JIT). > > Such policy might or might not make sense. It might make sense for ease > of reasoning, e.g. "I've flipped this setting, and now I'm certain the > system doesn't have JIT within a process (can still have it through > dynamically creating and invoking an entire new program), so there are > no opportunities for an attacker to inject code nor generate previously > non-existing ROP gadgets into an executable mapping within a process." > > I do find it questionable whether such policy and such reasoning make > sense beyond academia. > > Then, there might be even more ways in which W^X is not perfect enough > to enable such reasoning. What about using ptrace(2) to inject code? > Should enabling W^X also disable ability to debug programs by non-root? > We already have Yama ptrace_scope, which can achieve that at the highest > setting, although that's rather inconvenient and is probably unexpected > by most to be a requirement for having (ridiculously?) full W^X allowing > for the academic reasoning. > I am not suggesting that W^X be fixed. That is up to the maintainers of that code. I am saying that if the security subsystem is enhanced in the future with policies and settings that prevent the user tricks I mentioned, then it becomes impossible to execute dynamic code except by making security exceptions on a case by case basis. As an alternative to making security exceptions, one could convert dynamic code to static code which can then be authenticated. > Personally, I am for policies that make more practical sense. For > example, years ago I advocated here on kernel-hardening that we should > have a mode where ELF flags enabling/disabling executable stack are > ignored, and non-executable stack is always enforced. This should also > be extended to default (at program startup) permissions on more than > just stack (but also on .bss, typical libcs' heap allocations, etc.) > However, I am not convinced there's enough value in extending the policy > to restricting explicit uses of mprotect(2). > > Yes, PaX did that, and its emutramp.txt said "runtime code generation is > by its nature incompatible with PaX's PAGEEXEC/SEGMEXEC and MPROTECT > features, therefore the real solution is not in emulation but by > designing a kernel API for runtime code generation and modifying > userland to make use of it." However, not being convinced in the > MPROTECT feature having enough practical value, I am also not convinced > "a kernel API for runtime code generation and modifying userland to make > use of it" is the way to go. > In a separate email, I will try to answer this and provide justification for why it is better to do it in the kernel. > Having static instead of dynamically-generated trampolines in userland > code where possible (and making other userland/ABI changes to make that > possible in more/all cases) is an obvious improvement, and IMO should be > a priority over the above. > > While I share my opinion here, I don't mean that to block Madhavan's > work. I'd rather defer to people more knowledgeable in current userland > and ABI issues/limitations and plans on dealing with those, especially > to Florian Weimer. I haven't seen Florian say anything specific for or > against Madhavan's proposal, and I'd like to. (Have I missed that?) > It'd be wrong to introduce a kernel API that userland doesn't need, and > it'd be right to introduce one that userland actually intends to use. > > I've also added Rich Felker to CC here, for musl libc and its possible > intent to use the proposed API. (My guess is there's no such need, and > thus no intent, but Rich might want to confirm that or correct me.) > > Alexander Madhavan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel