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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A2AF1C04A94 for ; Wed, 16 Aug 2023 05:44:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D1ED18D001D; Wed, 16 Aug 2023 01:44:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CCF2F8D001C; Wed, 16 Aug 2023 01:44:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B6FBC8D001D; Wed, 16 Aug 2023 01:44:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 9F1CD8D001C for ; Wed, 16 Aug 2023 01:44:41 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 7CAC21A0E1C for ; Wed, 16 Aug 2023 05:44:41 +0000 (UTC) X-FDA: 81128878362.29.336271D Received: from nautica.notk.org (nautica.notk.org [91.121.71.147]) by imf24.hostedemail.com (Postfix) with ESMTP id 23019180013 for ; Wed, 16 Aug 2023 05:44:38 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=codewreck.org header.s=2 header.b=gxpolGni; dkim=pass header.d=codewreck.org header.s=2 header.b=Le9BCk3B; dmarc=pass (policy=none) header.from=codewreck.org; spf=pass (imf24.hostedemail.com: domain of asmadeus@codewreck.org designates 91.121.71.147 as permitted sender) smtp.mailfrom=asmadeus@codewreck.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692164679; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=4gbF64ZAps2tu8Us8hVmy7bZFfqOLG3YAt1/kY1ChvI=; b=Z0isakPkNPG9iWDQbZaJus0GQlJ0RXCb76if+rXQn4uVJgaNi5rhP8T3ThCgTo+1hX+HzR NSwyos/N/wCXDDfDulpAf4b9/nJoKgtwbzj1bYNyec/QfefIn5BI6XcNNFG17qAbZ/iF6f GVshTo9qwYFWyW1RTZEv2qfsJuAyEkQ= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=codewreck.org header.s=2 header.b=gxpolGni; dkim=pass header.d=codewreck.org header.s=2 header.b=Le9BCk3B; dmarc=pass (policy=none) header.from=codewreck.org; spf=pass (imf24.hostedemail.com: domain of asmadeus@codewreck.org designates 91.121.71.147 as permitted sender) smtp.mailfrom=asmadeus@codewreck.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692164679; a=rsa-sha256; cv=none; b=C/36XOqhUhGDatHY+X3gVSo8A3yX06delEV7b97MLy4vMEuo3LQxY5ZfDmi03I0Nw9IExx OIFur6/U7JjdzL8jNk5esLSxRKkaSrdF6kHM3nRaKMelm0UjOH/8d/b1P89iroDG/3C5K4 hNZD2NI94lvQpX+wtipAMdT6H2vI2Cg= Received: by nautica.notk.org (Postfix, from userid 108) id 5B8F4C01E; Wed, 16 Aug 2023 07:44:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codewreck.org; s=2; t=1692164677; bh=4gbF64ZAps2tu8Us8hVmy7bZFfqOLG3YAt1/kY1ChvI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=gxpolGnipyoWx6NOs1Wo2RpVLOc+yxa4jjFF12DjfWBz8Auah8rAfmB8pHTN3YuGu eLs5+UdNOMA9lhc71/oJTy2R9g1UIO11cPq2Z3tkaFLxJ8ytoyZ1pVn6wYv0CqbjFr QpIfTqw060s51OxpvNjQ7V49+nI3W2kebtvnxWk2IDtleiW+HeT/l/ukow9vtA+qRD vk8aWqdxw5A0qVyTGqm7i3CwvQY5nlCPAJH/04DeMhfpdFUmnOlmz9lFpuk6tOvyLG lgvW9zea711VF9wFQMFXnZbbkOe8AalL/QbxF4gTQAC1p1k/tUxJlwSAyQ8RPrBpiB Gik41FMsf2v9Q== Received: from odin (localhost [127.0.0.1]) by nautica.notk.org (Postfix) with ESMTPS id 2C5C1C009; Wed, 16 Aug 2023 07:44:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codewreck.org; s=2; t=1692164676; bh=4gbF64ZAps2tu8Us8hVmy7bZFfqOLG3YAt1/kY1ChvI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Le9BCk3BgokIeFhQZ+E2qn5OLRfVeXZzjZj6lNANgyEGwg69oTq4rzoHh3BlR2+ky VK9y9v0mZn9j0gHRq4yv8ICwuk5hMQqiuVQv1K7ifIlEASm3suPqJ8iJLyHZVw4yDL mAWxPdPvf505aXF6nXW8ZOLxRLR9y/01xn948nv0roYzxswTm08gkUYHE6offRFNMr ANBAlzKf0paytsaUQdQ2/XLSVoIwjgEsXq4IAIGcnXPkoCpzDSwfk8t8Wm/4tyKCNM ect0SxgtjREzw1KK+2kTc+huXX6/Xf0xmSgO9ulctpEPmqUgJpVa0OFv9UKN8Doo0g p2bvpBnLDL9ug== Received: from localhost (odin [local]) by odin (OpenSMTPD) with ESMTPA id 014ee523; Wed, 16 Aug 2023 05:44:28 +0000 (UTC) Date: Wed, 16 Aug 2023 14:44:13 +0900 From: Dominique Martinet To: Jeff Xu Cc: Aleksa Sarai , Andrew Morton , Shuah Khan , Kees Cook , Daniel Verkamp , Christian Brauner , stable@vger.kernel.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v2 4/5] memfd: replace ratcheting feature from vm.memfd_noexec with hierarchy Message-ID: References: <20230814-memfd-vm-noexec-uapi-fixes-v2-0-7ff9e3e10ba6@cyphar.com> <20230814-memfd-vm-noexec-uapi-fixes-v2-4-7ff9e3e10ba6@cyphar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 23019180013 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: y5o6i9minmg6dhj1dn73h1ac31nxbsoq X-HE-Tag: 1692164678-530034 X-HE-Meta: U2FsdGVkX1/FfeLovtXzH190b3nRXK9CDtVP4x6ejyTiPTkcUYNn4nuJthPU4HFgUpQWTGffLM0gS+ihOQrv3Zr6UtxA5XxTclY5B8bqzjsbP4ZpaigW9ILVL/3ev+spN040RMgj+ZNh5W8MOYYkijI4tOPxKmdPLrVi2J6Ae9/M2ktTTxb16QUuA45zXV6HPfYwHqxK3MqRrFEtla+5XM5ozWpkAvoY3S15uvwTSoQppj9kwnqDkvR8+vmaBllGdnFMEwjeqwbl48W/1i5tGKm+8TUIN1HjnxP+mdIU1/pZQE2ScgkQIbmAMMDCFar0X39i/fuS07baHH1Wse6ESaJ1bglTA9INfJtwIOHhg4oPPDfgfGqkektYzON5wXw/o6dAe0sQaU2VT2SeMLVDktWA9LbMwkk4WsRIBLDsUzoCdTjnr5kD/bdJmhzaQZpfGcrUI9Iqyf8Y5+pw4/9OcObuFYEuXBsAG8yfZZyFi4F0TuEEIg5ys5c2gxLXT+ROeaOivdsYqV9lYQoa2LqWlhQTvcbBSdj9vEbBfrccN8lBSo0+5yNwb0u0MUcyjhbPCIV+4uHBQC/H3/WOZqJvkuA9Sl4Fnasng3134SlSkYrTsiVJz0IRa8L3AUWqNHJj/eYiOrFx2/tnTfjrOdp5RjI2neWvDKxO6huK46ZrvG9/dKp33aQqix8d5BDqQaxCSiy6zFjQ/4RAdNWauYUw7yf+GwnsAMUcB4IhC0iU9DmrilCTszPigOfmgKjFaXH/oz3kpYMymzHhMooB6hKWU+v/cNDlj3jRhKH0tmR59q8OW5jz1Gg97jBHXxA99SvZqnDwOEclfm3AIG+UArEhv4YYM4h21Ed5cwQoJKARWTrM3bc/qHtdun0+g0u7++H+b4xhMqqagccz68Si7jRT3cSz5xQvshFDg4ft3V3SNBOFq2dHFl3LtCSJJWw2Fsni75mJDjrlo7gNkJkJr6h aMYHC9WT 67jGKmaKxdzXnx72pj7CQ880ZtvP2TtPFE/Ay8IDq2JFNUulvCas/eGl6rGY/X+d6ZGWLOlTZW0NLmWTjFhZHdF0Oa7oXkETbhsBeAF+/6ESjdaKP//c2kIVejkFPwvG+mua3zm+54ey1GHFsNRW4YbaRpr6EkqpWmKrOWjYBY5YuVt+Wo3vG/4PEW9QTLfqJeQKhKUYpYzZguXucLDE1SQ1f4L8TO81RDQ63 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Jeff Xu wrote on Tue, Aug 15, 2023 at 10:13:18PM -0700: > > Given that it is possible for CAP_SYS_ADMIN users to create executable > > binaries without memfd_create(2) and without touching the host > > filesystem (not to mention the many other things a CAP_SYS_ADMIN process > > would be able to do that would be equivalent or worse), it seems strange > > to cause a fair amount of headache to admins when there doesn't appear > > to be an actual security benefit to blocking this. There appear to be > > concerns about confused-deputy-esque attacks[2] but a confused deputy that > > can write to arbitrary sysctls is a bigger security issue than > > executable memfds. > > > Something to point out: The demo code might be enough to prove your > case in other distributions, however, in ChromeOS, you can't run this > code. The executable in ChromeOS are all from known sources and > verified at boot. > If an attacker could run this code in ChromeOS, that means the > attacker already acquired arbitrary code execution through other ways, > at that point, the attacker no longer needs to create/find an > executable memfd, they already have the vehicle. You can't use an > example of an attacker already running arbitrary code to prove that > disable downgrading is useless. > I agree it is a big problem that an attacker already can modify a > sysctl. Assuming this can happen by controlling arguments passed into > sysctl, at the time, the attacker might not have full arbitrary code > execution yet, that is the reason the original design is so > restrictive. I don't understand how you can say an attacker cannot run arbitrary code within a process here, yet assert that they'd somehow run memfd_create + execveat on it if this sysctl is lowered -- the two look equivalent to me? CAP_SYS_ADMIN is a kludge of a capability that pretty much gives root as soon as you can run arbitrary code (just have a look at the various container escape example when the capability is given); I see little point in trying to harden just this here. It'd make more sense to limit all sysctl modifications in the context you're thinking of through e.g. selinux or another LSM. (in the context of users making their own containers, my suggestion is always to never use CAP_SYS_ADMIN, or if they must give it to a separate minimal container where they can limit user interaction) FWIW, I also think the proposed =2 behaviour makes more sense, but this is something we already discussed last month so I won't come back to it as not really involved here. -- Dominique Martinet | Asmadeus