From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 27A8B4A23 for ; Thu, 27 Aug 2026 19:39:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787859554; cv=none; b=TCmFeRSNkvsA09GXon1V3xXEU5olgDulLO23lupqCNnpgxCOdS8fWBOE0d3tNXyRetII8DFo7agsqIlwvVF+qIvJdkONWcsKtx0nZdbo5AgNW0bdDmskAUJy6VbeZkw9uD71b3B+Uwy/CXtWEWxUmXrJymq3bVpeFGKiA/ReLcQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787859554; c=relaxed/simple; bh=iPf7ChaqIsVoGcvfLFkYqgjfgPL7ty9oLZe40l5pQ94=; h=Date:Message-ID:MIME-Version:Content-Type:From:To:Cc:Subject: References:In-Reply-To; b=V2QfnbnpsGn6aui5uiBkfxAblrOIgzishOgj/sN1NpPArH9FP/AY7yMfCV/+at9NrpH4VtiFrc9TRY6sbMassuOuKcBEtOkE3F7fHONZlQjPQ9YsregoTCBaRfl/nB0nUetbRFZQUFYTrY1xpJGb+4gDnfTrmC1JSk0FtKqtYQY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=paul-moore.com; spf=pass smtp.mailfrom=paul-moore.com; dkim=pass (2048-bit key) header.d=paul-moore.com header.i=@paul-moore.com header.b=HpOZ5ZZW; arc=none smtp.client-ip=209.85.219.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=paul-moore.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=paul-moore.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=paul-moore.com header.i=@paul-moore.com header.b="HpOZ5ZZW" Received: by mail-qv1-f46.google.com with SMTP id 6a1803df08f44-90ce08834feso1418296d6.0 for ; Thu, 27 Aug 2026 12:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore.com; s=google; t=1787859552; x=1788464352; darn=vger.kernel.org; h=in-reply-to:references:subject:cc:to:from:content-transfer-encoding :content-type:mime-version:message-id:date:from:to:cc:subject:date :message-id:reply-to:content-type; bh=mtXig1FMjrSYmMbsrTikOQfn2mLp1bwY+1B2vUa6dN4=; b=HpOZ5ZZW8h78vYnfkwrPzKV8DX0KqSCR//l4g862xZTEXiKVVxyIcR2zzsem301V5o P/4fPlMtdSMoYxb3tqRXMVZnPeaLd4uWE713kzq1d3jwoxdnDwKE5FuOY3gZXTJblRak QQkjj5JncGdZ3w3Dq4iveA73hPubX69bFD3/I2G82ECysx4QaH/2KgUtdEPDvEFenTUZ jYRhuLyJ4KzX9ZoAcjQsDbqtuBA+6TRMr+uxDibVsiMXe118kJGre5+Ic8Hx+0fusc5z T/YZ+lgB4Ojagsb3774ECWnXt5iNCShHu3rzfaJJAIEAqIXHvT20aofkChCffRUTrvk/ fmtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787859552; x=1788464352; h=in-reply-to:references:subject:cc:to:from:content-transfer-encoding :content-type:mime-version:message-id:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=mtXig1FMjrSYmMbsrTikOQfn2mLp1bwY+1B2vUa6dN4=; b=WERm5PxztRNokOYkbmXyTI5hrw4DjfFpH0VAZx33UtwZBr133o3vXPCUE3Q6wSJoSP 6SxEg5BBVR7dn6W/zdqDO4VzGfKZAemCc1WoxKtd8YfhpDvs8uNXEC18mvym5U1q5QpM SsfCsaX2X5Oges5EOGKq46RQDBoT05YghcpK4yRsgVWCtlK50Gq3NNK2VtFAxmip7d0r mnVjzhqF440BgnGj0iehzQtwz8PhsPer5XlAsJWDV+9SSl1WDRe1tqcMYTFTeFI80upN OBt+sW0qkGT5nSiQ7S9YxDD4T9y34RhfTiBwZYio2DimeVuWsZSUz+dBiVESQYZ1lPQC kG2w== X-Forwarded-Encrypted: i=1; AHgh+RrDMsTw68BT4+jOCcHif9gWpvRFDMLoeXxvrj11JeL6fyj3wezpIdAUNT2TelMPIB3T1Zq0QYoJXYZoFuY=@vger.kernel.org X-Gm-Message-State: AFuF++m3ZZyOJo/1G5M7iSACIUWJWIel2la/ThPO8TjmyeZqdMdU0uj6 cCrQLQ9XwrE6Mam2BINF5ygyWU6n9M781HP5DeIJvuvShJjjPVq27+vFxEZ1ywa2mg== X-Gm-Gg: AR+sD11Cz5bvxnTQjoMABD5faurA4u9Cn17UU8ipDfgn+0Qt5ovpgUAZcK3jor4kn9M +nyI8BhPzqpJyxlr1VBKs4twijIjA9WgWceD1xewSiQK0XL8zRSnoxkZCqfGrEUyBhiqAjrxsmi ZhyM2HiMXKuToWvmn4yAH/jp3Y2nrZxLcOOfExnKf3TtK4lbxL/cTOHjRYOP6jRwfDvAaKa6LuI WUH0ysMHozSdpH2UPrG1+NUte9u3+hNXJqSYnVZfW/6+96jNEvn6aehjQHaFu0s/joXRoBRsTEE egzTgbeUA8R5zUdnQHnqOxg8q7+CrVBXC7BWofgWLZ2fmE2qMLDMrraP/4bwLKihS7ezWAm1aLO wSASkuKDaJJmMyfQLx5fR1n4KDBHg8kUu+1vxFXdrrsP26Lt4z7T7CjxKVzvMija+D7kfwTXyIS y43LPDE5EouA/UEmgK0MULKBNy4JQM4U9Nf/IMhOJvsv7AV7Cl4M+d55ROjWCuPehHq2fWKhTqd 98cFzDq8OptE/isoDFFETUR98bFXK3mvKm0kcKbB2pk X-Received: by 2002:a05:6214:e43:b0:908:9fd5:ed42 with SMTP id 6a1803df08f44-90ce0f06bdbmr20681366d6.28.1787859551742; Thu, 27 Aug 2026 12:39:11 -0700 (PDT) Received: from localhost (pool-71-126-255-178.bstnma.fios.verizon.net. [71.126.255.178]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-90cd73fc28dsm24026946d6.34.2026.08.27.12.39.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 12:39:10 -0700 (PDT) Date: Thu, 27 Aug 2026 15:39:10 -0400 Message-ID: <5fa5ef078f41cd57d0e52ab2ab023094@paul-moore.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailer: pstg-pwork:20260827_1122/pstg-lib:20260827_1501/pstg-pwork:20260827_1122 From: Paul Moore To: Karl Mehltretter , selinux@vger.kernel.org Cc: Karl Mehltretter , Stephen Smalley , Ondrej Mosnacek , Miklos Szeredi , Amir Goldstein , Christian Brauner , linux-fsdevel@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH v2] selinux: preserve user SID across nested backing files References: <20260820175832.44512-1-kmehltretter@gmail.com> In-Reply-To: <20260820175832.44512-1-kmehltretter@gmail.com> On Aug 20, 2026 Karl Mehltretter wrote: > > SELinux saves the user file SID in a backing-file security blob so it > remains available after mmap() replaces vma->vm_file with a backing file. > > For nested backing files (overlayfs over overlayfs, or FUSE passthrough > backed by overlayfs), user_file may itself be a backing file. Its > fsec->sid is the SID of the mounter that opened it, rather than the user > that opened the top-level file. mprotect() then checks fd { use } against > the mounter SID. This can incorrectly deny access without a domain > transition, or check the wrong target SID after one. > > Copy the saved user SID when user_file is a backing file. Keep using the > regular file SID for the first backing layer. > > With two nested overlayfs mounts and SELinux enforcing, > mprotect(PROT_READ) returns EACCES with an fd { use } denial against the > mounter SID. With this change, mprotect() succeeds. > > Fixes: 82544d36b172 ("selinux: fix overlayfs mmap() and mprotect() access checks") > Cc: stable@vger.kernel.org > Assisted-by: Codex:gpt-5.6-sol > Signed-off-by: Karl Mehltretter > Reviewed-by: Amir Goldstein > --- > Changes in v2: > - Add selinux_file_user_sid() helper instead of open-coding the lookup > (Amir). > > Tested on arm64 QEMU at fd6e2388a3ea with SELinux enforcing and two > nested overlayfs mounts. The policy omitted only > base_t -> mounter_t:fd { use } among the relevant cross-domain allows: > > baseline: mprotect(PROT_READ) returned EACCES with that denial > patched: mprotect(PROT_READ) succeeded; test exited 0 If you could share the distro and some more details on the testing methodology that would be helpful. > This patch fixes SID propagation only. backing_file_user_path() still > resolves to the middle layer for a nested mapping, so the audit path and > inode do not correspond to uf_sid, and that layer's mounter is not > re-checked. Preserving the full user path likely needs a VFS-side change, > such as having backing_file_open() store file_user_path(user_file). Additional comments below, and while this patch is useful in fixing some of the problems (thank you!), we obviously need to fix the others as well. Is this something you think you will be able to work on? > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c > index 1ead2eee1944..171b90412ff1 100644 > --- a/security/selinux/hooks.c > +++ b/security/selinux/hooks.c > @@ -3843,13 +3843,20 @@ static int selinux_file_alloc_security(struct file *file) > return 0; > } > > +static inline u32 selinux_file_user_sid(const struct file *file) > +{ > + if (unlikely(file->f_mode & FMODE_BACKING)) > + return selinux_backing_file(file)->uf_sid; > + return selinux_file(file)->sid; > +} I'm a little concerned that this only works for one additional level of filesystem stacking. Yes, I know that OVL_MAX_NESTING and FILESYSTEM_MAX_STACK_DEPTH are currently set at "2", but it's not an unreasonable concern that at some point in the future that number will increase without proper notification or testing and we will once again have a problem. At the absolute minimum we should have a BUILD_BUG_ON() for the stacking depth. It would be good if we could watch both the overlayfs and vfs constants, but the overlayfs constant isn't available outside fs/overlayfs/inode.c (thankfully it is currently set to the vfs limit). BUIILD_BUG_ON(FILESYSTEM_MAX_STACK_DEPTH > 2); Ideally, the code would be written to keep diving down the stack until it hit the true backing file. No one likes to see recursion, but at the point where this function is called there should already be a reasonable bound on the stacking depth and the work involved. -- paul-moore.com