From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-bc0d.mail.infomaniak.ch (smtp-bc0d.mail.infomaniak.ch [45.157.188.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4427830C110 for ; Thu, 18 Sep 2025 14:07:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.157.188.13 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758204474; cv=none; b=GaUU2KeudVAJhpgo729K/7oB60MwVC/yAZ6Oarlmc5CNOzFOdGr8nqwg6h7JAaklNeIhMto26wQx03/lL/nJNelZG/iEYYb7FrHVFfkgn3qxcoE7kU49T/LTM2M6usIQtRz/v2AKqiSdljBwEMUeQ9L/SYYQ+PmDjTMYdWdfsZE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758204474; c=relaxed/simple; bh=KLL9YJXtSSSZ1Vd0/isQrxMphZZqXIjYKKJpaSBPKo4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Hk1MFdckf2jDCAz7XKOWH3A8nUexznI4GgBbOzm7q2EDJpCtjLV0/q8PDc4eWCou/+kZozp1gAXPgx0862lmk2nYm8PEEbbF8Nx1Om47w+4hJzWX+PuyvABDEK0cKYA/wyQdBO2vGy/gGOXjLSR+WrSWIxz0QPdI0DynzGHF+l4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=digikod.net; spf=pass smtp.mailfrom=digikod.net; dkim=pass (1024-bit key) header.d=digikod.net header.i=@digikod.net header.b=XtILx/zR; arc=none smtp.client-ip=45.157.188.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=digikod.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=digikod.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=digikod.net header.i=@digikod.net header.b="XtILx/zR" Received: from smtp-4-0001.mail.infomaniak.ch (unknown [IPv6:2001:1600:7:10::a6c]) by smtp-4-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4cSHXN2pvBznsr; Thu, 18 Sep 2025 16:07:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digikod.net; s=20191114; t=1758204468; bh=vVKOs9N1kLsZNFyRJ52LmCjCUC7Qes6mPkdcbujsc20=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XtILx/zREilfKNPvUphCInZ9NyXZCREZmkr3va/pK38KPQmvCT7r3aNiMvEe3g5yf NQIAWHYCLNkKeevf/KYc1jX1Dx0rSIPxw3s2V/1Zfwy+IIG7W8p/XGCS0XG8way6na kGyL8Mz14mNHZcAmfKn3Hcruo4Wpy6u5cICPdD/8= Received: from unknown by smtp-4-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4cSHXM4HPxzZ8T; Thu, 18 Sep 2025 16:07:47 +0200 (CEST) Date: Thu, 18 Sep 2025 16:07:46 +0200 From: =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= To: Abhinav Saxena Cc: Fan Wu , =?utf-8?Q?G=C3=BCnther?= Noack , Paul Moore , James Morris , "Serge E. Hallyn" , Shuah Khan , Nathan Chancellor , Nick Desaulniers , Bill Wendling , Justin Stitt , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, llvm@lists.linux.dev, Daniel Verkamp , Jeff Xu Subject: Re: [PATCH RFC 2/4] landlock: implement memfd detection Message-ID: <20250918.kieghied1ahS@digikod.net> References: <20250719-memfd-exec-v1-0-0ef7feba5821@gmail.com> <20250719-memfd-exec-v1-2-0ef7feba5821@gmail.com> <87v7nj7p1d.fsf@gmail.com> Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87v7nj7p1d.fsf@gmail.com> X-Infomaniak-Routing: alpha On Tue, Jul 22, 2025 at 03:56:38PM -0600, Abhinav Saxena wrote: > Fan Wu writes: > > > On Sat, Jul 19, 2025 at 4:13 AM Abhinav Saxena wrote: > >> > >> Add is_memfd_file() function to reliably detect memfd files by checking > >> for “memfd:” prefix in dentry names on shmem-backed files. This > >> distinguishes true memfd files from regular shmem files. > >> > >> Move domain_is_scoped() to domain.c for reuse across subsystems. > >> Add comprehensive kunit tests for memfd detection edge cases. > >> > >> Signed-off-by: Abhinav Saxena > >> — > >> security/landlock/domain.c | 67 +++++++++++++++ > >> security/landlock/domain.h | 4 + > >> security/landlock/fs.c | 210 +++++++++++++++++++++++++++++++++++++++++++++ > >> security/landlock/task.c | 67 ————— > >> 4 files changed, 281 insertions(+), 67 deletions(-) > > > > … > > > >> > >> +/** > >> + * is_memfd_file - Check if file was created via memfd_create() > >> + * @file: File to check > >> + * > >> + * Returns true if @file was created via memfd_create(), false otherwise. > >> + * > >> + * memfd files are shmem-backed files with “memfd:” prefix in their dentry name. > >> + * This is the definitive way to distinguish memfd files from regular shmem > >> + * files. > >> + */ > >> +static bool is_memfd_file(struct file *file) > >> +{ > >> + const struct dentry *dentry; > >> + const unsigned char *name; > >> + size_t name_len; > >> + > >> + /* Fast path: basic validation */ > >> + if (unlikely(!file)) > >> + return false; > >> + > >> + /* Must be shmem-backed first - this is the cheapest definitive check */ > >> + if (!shmem_file(file)) > >> + return false; In which case a memfd would not be detected by this function? shmem_file_operations or hugetlbfs_file_operations are always set for memfd right? We could export memfd_get_seals() to stay consistent over time. > >> + > >> +#ifdef CONFIG_MEMFD_CREATE > >> + > >> + /* Validate dentry and get name info */ > >> + dentry = file->f_path.dentry; > >> + if (unlikely(!dentry)) > >> + return false; > >> + > >> + name_len = dentry->d_name.len; > >> + name = dentry->d_name.name; > >> + > >> + /* memfd files always have “memfd:” prefix (6 characters) */ > >> + if (name_len < 6 || unlikely(!name)) > >> + return false; > >> + > >> + /* Check for exact “memfd:” prefix */ > >> + return memcmp(name, “memfd:”, 6) == 0; > >> +#else > >> + return false; > >> +#endif > > > > I was trying to do something similar early this year but didn’t hear > > feedback from the linux-mm folks. > > > > > > I have considered this approach but didn’t use it. My concern is, > > potentially a malicious user can create a file in a shmem fs, e.g. > > tmpfs , with the “memfd:” prefix, which can be used to bypass security > > policy. In the case of Landlock that should not be a security issue but a compatibility issue, which is not better. > > (Resending this message due to a misconfiguration with my email > > client. Apologies for any inconvenience.) > > > > -Fan > > Hi Fan, > > Thanks for your comments. > > I agree that an LSM hook into memfd_create() would be a much better > solution. In the absence of such a function, do you think adding a > `d_unlinked(dentry)` check could serve as an additional verification? > > I say things since I *think* that legitimate memfd files are always > unlinked while spoofed tmpfs files remain linked. I could be wrong > though. We should just use the same checks used by the memfd-related syscalls/operations to detect such file. > > In any case, we can test this approach using kprobes to validate > the behavior. > > -Abhinav