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 66870E77188 for ; Tue, 7 Jan 2025 01:26:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F0AC36B0083; Mon, 6 Jan 2025 20:26:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EB9256B0089; Mon, 6 Jan 2025 20:26:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DA7BA6B008C; Mon, 6 Jan 2025 20:26:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id B84D86B0083 for ; Mon, 6 Jan 2025 20:26:47 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 658631A0553 for ; Tue, 7 Jan 2025 01:26:47 +0000 (UTC) X-FDA: 82978916454.28.D16537C Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) by imf21.hostedemail.com (Postfix) with ESMTP id 667A91C0006 for ; Tue, 7 Jan 2025 01:26:45 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=GK5BmBIm; spf=pass (imf21.hostedemail.com: domain of isaacmanjarres@google.com designates 209.85.214.178 as permitted sender) smtp.mailfrom=isaacmanjarres@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736213205; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=M372tjeIGF/B6j8tuFkO5rd4a50LQoTcJMIW9ilW1lM=; b=wKTZXVxcS36SABWMKGeKC44UT4Ln/QC+/bm410lLJqbBKrrzCfAEpW7598s7cldBSTQiWj 6VWm6HMsARbDO51VHMgLIgMzWCbxdfQytgjQm/U7mVGEQo6WtnnSLFR0UQGgmDMaSfNh+V UvjzklojaIots97AYH3NGEZB9nCEjw0= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=GK5BmBIm; spf=pass (imf21.hostedemail.com: domain of isaacmanjarres@google.com designates 209.85.214.178 as permitted sender) smtp.mailfrom=isaacmanjarres@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736213205; a=rsa-sha256; cv=none; b=5GSBgD3EE35f1GbsC/+2pKZUnKSLL/qcEAbEYjwFM9RAdOr6YMg0zcZp4G9nINTVvcsCRM Neja5LLuBjwiYzo1j7QlbqdS3S92Ep4l1wCKg2e6BmPfJIobpjsavF4dD7/dW7+/KmkD+G JvM6KIfm0agj2OkoRHkQAi1DDfn6KNI= Received: by mail-pl1-f178.google.com with SMTP id d9443c01a7336-215740b7fb8so65705ad.0 for ; Mon, 06 Jan 2025 17:26:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736213204; x=1736818004; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=M372tjeIGF/B6j8tuFkO5rd4a50LQoTcJMIW9ilW1lM=; b=GK5BmBImWniTr5Vk3FHLecjxwTk0UfVKfnWjtqSpeD5WYaLvFpDzDD9tpvWvVxGaBx 1TMl3m473l+NC/BBe+fV4aIhaYxfFJhuq3O9kwPQTpfW5JJJAwHrRLCnH69/AYYL3jO9 Cs9M7Z1f+6kpatOmGxbGb5UhXZ+og3fPQVB+/QCUL/iEjRRpjiMDPTvCEqBsdSmv/6de ayi0+hfzIyk832LBynhpdUEVr6ha3qrJejTP+U3n7TuXtkUr/xbRAsI8Dv6w8sXnI8Ol Gm5BeZcRVO+2+kmcd8gqjbR3TOPkq+owQyMI61mj8XV+KHH2ACJ75Q1TYe9tza5neCMd YD6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736213204; x=1736818004; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=M372tjeIGF/B6j8tuFkO5rd4a50LQoTcJMIW9ilW1lM=; b=D8SfCqLMapNVerZLD5Drhmv4pRxNP945y6W2XsDSySEHKGy064ajdvRREJXMfOWSkd JZKZ7Zhenilt1aO1rB+9i57U+dbqumi4Dv8o/TebLfDxCIJ50izkCyocq3yyjWVUzmVN L1OE5BC6KBngtiZ/qmXWG+21p5l0wCBk4r94UisJBKxp6gcFOftMRomoJcGy5T+exGeP uEthMO8Ww+G92j52QoyFCOwztiNjFO+3GW2r4ziDd8HWRDuq1fejPQMI11J5B+gzJhYT mONPrjgFvPh7JBZQc4ylQPLjIiDNnUYfeuHS8F0pLbgXMxJvt+UKizpzbfTtYGi4PoAY WHpg== X-Forwarded-Encrypted: i=1; AJvYcCXzgFypX96LgnMUvYPnDmNl2sxlwMS6vx7oY5pO1NLVPdy4KJgQCL9ZFzAzG42zfWyZ3LsJ4s0QMw==@kvack.org X-Gm-Message-State: AOJu0YyewPk0gDNWCd73BqN6ARrt4VwCTGeinQYoBxDxkk5AmmTDz6VI OYq1CIjGlDRODze3L4Lx/xfkyfAkHr/cAE3qabSeA5rp5GUkKAQ2rZWonJSHiw== X-Gm-Gg: ASbGncv9FanvA2xxrf13Owg+yi11IvqN8mmBUw9WrEN2f4xZvW4AVnwSkt2aweQ14Jn IZbqlfm1nCohUJsElbBm6F2/81tem+iIyTB/daeDtGUgmRasXptUlXqEAysNp28uEtlt2WIPL5z mrcA3RiiPKcAMrr6aOr0Qkn0v2ATZaKuXWhrBRG5eHe5ZZ6WQSK70mqVtGPCwTIz9CSd3XT+V5C djSlX/izM5DHEgnAeLmDe4X+iwsvL2JGNG6xiMKmYcy4L+ewPh+MJAs X-Google-Smtp-Source: AGHT+IFUje41UqMGChKWwoUXHu8SMmzrXD2rW9ZDvE3vXGz/NkrxhtzEWY6tO9tH8NrLIu1jBzPmiQ== X-Received: by 2002:a17:902:e849:b0:216:48d4:b3a8 with SMTP id d9443c01a7336-21a7acca8ddmr1058805ad.16.1736213202325; Mon, 06 Jan 2025 17:26:42 -0800 (PST) Received: from google.com ([2620:15c:2d:3:42b3:1d33:ab4b:8279]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-72aad8dbb70sm32188398b3a.98.2025.01.06.17.26.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Jan 2025 17:26:41 -0800 (PST) Date: Mon, 6 Jan 2025 17:26:37 -0800 From: Isaac Manjarres To: Jeff Xu Cc: Jann Horn , Kees Cook , lorenzo.stoakes@oracle.com, Jeff Layton , Chuck Lever , Alexander Aring , Andrew Morton , Shuah Khan , surenb@google.com, kaleshsingh@google.com, jstultz@google.com, aliceryhl@google.com, jeffxu@google.com, kees@kernel.org, kernel-team@android.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org Subject: Re: [RFC PATCH RESEND v2 1/2] mm/memfd: Add support for F_SEAL_FUTURE_EXEC to memfd Message-ID: References: <20250102233255.1180524-1-isaacmanjarres@google.com> <20250102233255.1180524-2-isaacmanjarres@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 667A91C0006 X-Stat-Signature: xxb41z7apihw1owq6eoq91nbj75at8es X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1736213205-964622 X-HE-Meta: U2FsdGVkX18pFBAbmA4dUxY/MxdQJpL8XZH6xQB14Us2MZ0MGBTSWkbk31jVZDE0XFeM+aIBR+IDcFTyNEpaKlojJUaco+Ez/A5I8wo9z1d4DNjybTG0TAS+CF/f4KDMxrx0ZwRVFRRKBWlF9v52IeEkNt9Ai3dQ5yyYhabdkbZj5Y+MAydJcHa0JVaBj69p3f8dAV/39raoK0ZcqQ1EsQdCFTO7nxG3HQaHYlAF5vLkgkIaaHOWONewovgaDOwsUZttMxNdWsJ0jBfVfGPrsrUBhAIrcdlTj3V6TKxndSzpk5Kx1DASIhICEHfpUzXkvaJI6k6MG/6CGXSJN9T8lbF8vJRwITRy055OZxzIcWBAdYX4+U6mz0vBHAYAHZ+R7CP8VLBR1RQE9wmiKCtmftfdVWGUkeWWKgRgJlbOh6k4SuQlxF7wSWXJ+yTKxrw56uxWP7KLA+se9JS7lJVy3FhVdPm6qAdP6H8Rv48D+KkiaCwAavEfMVzghArYMGIu4uSVhI4ySY1jEw7EYaRNlbiVJTGf7WrNysWnBd6k7L2bQfCnf6pxg9x9YXyjH31hVWSaJF1P9Cst0vI6ubeoRqnpMZHdSq8F8UfaTHc54SkkPEnjknJGZUPybnT7YwM+xYrO3+fjLFHa0+03oxlctAigZa5oQ1jAohGnNl2sbWqxFMZTi8VjD8YDxo2qkabf+P4yzpZVSMu3g9BHa5hZEtE3Xw+1GMHPI7Fg5/epw7/ReNd9L+N+Wj/vcTUCsDR2bD796YceIDhjSPi+m10Y0eIsrocbgf2fOVaOzzKlVe2Nm7vxTM1fGlSDmgsMSUO+rep+0+8blwa5DIMT5aD8Bq03HyrDRASv22/iEBZzDuvr+1r3GwOdBcd3JiSbhvHInzwuC6ZqizMv1pr8K+HpdQWWEfhW3aoDaPVgvDbvGFOb/9rWaVYEoSxnX493gkl4D2mV5Mv/O2osuPDBVts QqYZiBRk 9oTXWV0XABzFRzL5f5MnuZXvfunPpZ+SEHHAMbr3jiADD8sHtDRt8mYx+kiV1UHfuQLIfiab8imPVuba7l1lmMMEu5ybDLqGEpSmXD5qhI024xUelwVjsZja+vEI7RzBs6ZDhifANA9vtn+1p6r0PqGkf2IS0/V7pLhfKtKcAQnVWZ8JBtVWmR3NaWJeOpMLXSCPX9dqR4mcaFtLusoYbwrP9DWLxAvHPmOcx5DMQgs9s5RfME+KfspSDQQEjYSqjbA2uPyhigTqSBVP1KFfMwjA6YXBrtXxQ0Uj8qt+DQN6f70Jq2GzHaQ2MSA7fI/K0q1tV+BNKrlRgH8yXjfg4BCT9repYkW4mG+V/CWDW8fYLLzll/CdL9HyDcTqQMsiZ9Fdo3ip4MjMK8Sy4QsmLqFnzZoM7QyGA2hKdy9Rk8JWvip6CzoyZ278vK04SkwjM/aFwhBdxIIdn/aPGHGrq/CX3HpVq0I40Xaps/cuwBRuJU9dzuXMIP18bnsm5IZveu94a7JC5004v9jR087n8aoWj4Q== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000982, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Jan 06, 2025 at 09:35:09AM -0800, Jeff Xu wrote: > + Kees because this is related to W^X memfd and security. > > On Fri, Jan 3, 2025 at 7:04 AM Jann Horn wrote: > > > > On Fri, Jan 3, 2025 at 12:32 AM Isaac J. Manjarres > > wrote: > > > Android currently uses the ashmem driver [1] for creating shared memory > > > regions between processes. Ashmem buffers can initially be mapped with > > > PROT_READ, PROT_WRITE, and PROT_EXEC. Processes can then use the > > > ASHMEM_SET_PROT_MASK ioctl command to restrict--never add--the > > > permissions that the buffer can be mapped with. > > > > > > Processes can remove the ability to map ashmem buffers as executable to > > > ensure that those buffers cannot be exploited to run unintended code. > > > > Is there really code out there that first maps an ashmem buffer with > > PROT_EXEC, then uses the ioctl to remove execute permission for future > > mappings? I don't see why anyone would do that. > > > > > For instance, suppose process A allocates a memfd that is meant to be > > > read and written by itself and another process, call it B. > > > > > > Process A shares the buffer with process B, but process B injects code > > > into the buffer, and compromises process A, such that it makes A map > > > the buffer with PROT_EXEC. This provides an opportunity for process A > > > to run the code that process B injected into the buffer. > > > > > > If process A had the ability to seal the buffer against future > > > executable mappings before sharing the buffer with process B, this > > > attack would not be possible. > > > > I think if you want to enforce such restrictions in a scenario where > > the attacker can already make the target process perform > > semi-arbitrary syscalls, it would probably be more reliable to enforce > > rules on executable mappings with something like SELinux policy and/or > > F_SEAL_EXEC. > > > I would like to second on the suggestion of making this as part of F_SEAL_EXEC. Thanks for taking a look at this patch Jeff! Can you please elaborate some more on how F_SEAL_EXEC should be extended to restricting executable mappings? I understand that if a memfd file is non-executable (either because it was made non-executable via fchmod() or by being created with MFD_NOEXEC_SEAL) one could argue that applying F_SEAL_EXEC to that file would also mean preventing any executable mappings. However, it is not clear to me if we should tie a file's executable permissions to whether or not if it can be mapped as executable. For example, shared object files don't have to have executable permissions, but processes should be able to map them as executable. The case where we apply F_SEAL_EXEC on an executable memfd also seems awkward to me, since memfds can be mapped as executable by default so what would happen in that scenario? I also shared the same concerns in my response to Jann in [1]. > > > diff --git a/mm/memfd.c b/mm/memfd.c > > > index 5f5a23c9051d..cfd62454df5e 100644 > > > --- a/mm/memfd.c > > > +++ b/mm/memfd.c > > > @@ -184,6 +184,7 @@ static unsigned int *memfd_file_seals_ptr(struct file *file) > > > } > > > > > > #define F_ALL_SEALS (F_SEAL_SEAL | \ > > > + F_SEAL_FUTURE_EXEC |\ > > > F_SEAL_EXEC | \ > > > F_SEAL_SHRINK | \ > > > F_SEAL_GROW | \ > > > @@ -357,14 +358,50 @@ static int check_write_seal(unsigned long *vm_flags_ptr) > > > return 0; > > > } > > > > > > +static inline bool is_exec_sealed(unsigned int seals) > > > +{ > > > + return seals & F_SEAL_FUTURE_EXEC; > > > +} > > > + > > > +static int check_exec_seal(unsigned long *vm_flags_ptr) > > > +{ > > > + unsigned long vm_flags = *vm_flags_ptr; > > > + unsigned long mask = vm_flags & (VM_SHARED | VM_EXEC); > > > + > > > + /* Executability is not a concern for private mappings. */ > > > + if (!(mask & VM_SHARED)) > > > + return 0; > > > > Why is it not a concern for private mappings? > > > > > + /* > > > + * New PROT_EXEC and MAP_SHARED mmaps are not allowed when exec seal > > > + * is active. > > > + */ > > > + if (mask & VM_EXEC) > > > + return -EPERM; > > > + > > > + /* > > > + * Prevent mprotect() from making an exec-sealed mapping executable in > > > + * the future. > > > + */ > > > + *vm_flags_ptr &= ~VM_MAYEXEC; > > > + > > > + return 0; > > > +} > > > + > > > int memfd_check_seals_mmap(struct file *file, unsigned long *vm_flags_ptr) > > > { > > > int err = 0; > > > unsigned int *seals_ptr = memfd_file_seals_ptr(file); > > > unsigned int seals = seals_ptr ? *seals_ptr : 0; > > > > > > - if (is_write_sealed(seals)) > > > + if (is_write_sealed(seals)) { > > > err = check_write_seal(vm_flags_ptr); > > > + if (err) > > > + return err; > > > + } > > > + > > > + if (is_exec_sealed(seals)) > > > + err = check_exec_seal(vm_flags_ptr); > > > > memfd_check_seals_mmap is only for mmap() path, right ? > > How about the mprotect() path ? i.e. An attacker can first create a > RW VMA mapping for the memfd and later mprotect the VMA to be > executable. > > Similar to the check_write_seal call , we might want to block mprotect > for write seal as well. > So when memfd_check_seals_mmap() is called, if the file is exec_sealed, check_exec_seal() will not only just check that VM_EXEC is not set, but it will also clear VM_MAYEXEC, which will prevent the mapping from being changed to executable via mprotect() later. [1] https://lore.kernel.org/all/Z3x_8uFn2e0EpDqM@google.com/ Thanks, Isaac