From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (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 D49A72771F for ; Fri, 24 Mar 2023 22:45:27 +0000 (UTC) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 7EC383200977; Fri, 24 Mar 2023 18:45:26 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Fri, 24 Mar 2023 18:45:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tyhicks.com; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1679697926; x=1679784326; bh=7YaECwlWAb2rNWL4oDYUcOdn3UHmJY1t4LZ axuY9iyU=; b=f8LifDK0wPtGXdGHdfS2+RnKTFCP2SBVGWXFIH9wBoqJPzX+VTh C8tIsqkJJY+BCuDAbLG2T1Pa0FwaAGSqv4uPqEl10Rp3SuI20MlnyikhrVHtU3v8 sdym5fEfeonTbifHo9hbcLQPUWIWImnFTITE8l8NOMXrKewlPLzyzIQ0Gg4itDx0 wRHR/zRGLvPkfuEzcZ8XAZC5mHK6/xhgPV3PqkqTKcCkN7r8FoZKGeNxdrhpsqPX b8VQpcvFpPVrTvO6i2iJIxH4GlFnolGC2xpOzWfxsMaISOjZWEikeKaGiYmItKwV ppTUTFRuFIP3IB0Z1hjIHUvIJdBozhVbJ5Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1679697926; x=1679784326; bh=7YaECwlWAb2rNWL4oDYUcOdn3UHmJY1t4LZ axuY9iyU=; b=SgQxgdZujV/YbtVZtVxNlDD6vj3RhbwB8KOpRmBSGEx5WD0nerM jF1FTGDnPJh1RVy2E9O8JvBQ6dgjNTVoomX4WoyJU2F6GPjXjeUQ5hOC3pf0jSCg 3S3QqqSs8LdDBrWnviCXiRPY3ZyDI3Y4O194R2CamVbvlMGJ0fycXFZ4p8rFkHEt P/QO2nx0pVs2uCIQsWDb/Y7atpyD6es+eKEeaIl7WhC4nkBlZunzIkls+sgqkIpc ME/mvSBNo7v1drT6cxLNak0CoAyvqPE3nrz26KieWAijcm/e5KeOIlewnJhQKaEX MZIVWhGsZYta8ivExMVJbsRAaHCzvcOfosA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdegjedgtddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggugfgjsehtkeertddttdejnecuhfhrohhmpedfvfih lhgvrhcujfhitghkshculdfoihgtrhhoshhofhhtmddfuceotghouggvsehthihhihgtkh hsrdgtohhmqeenucggtffrrghtthgvrhhnpeeguddtjeekleekuddtjedvleegvddtveev keegleehhfekheejveehfeekfeduieenucffohhmrghinhepkhgvrhhnvghlrdhorhhgpd husghunhhtuhdrtghomhdprghskhhusghunhhtuhdrtghomhenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtohguvgesthihhhhitghkshdrtg homh X-ME-Proxy: Feedback-ID: i78e14604:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 24 Mar 2023 18:45:24 -0400 (EDT) Date: Fri, 24 Mar 2023 17:45:23 -0500 From: "Tyler Hicks (Microsoft)" To: =?iso-8859-1?Q?G=FCnther?= Noack Cc: =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= , Christian Brauner , landlock@lists.linux.dev, linux-security-module , Linux-Fsdevel , Al Viro , eCryptfs Subject: Re: Does Landlock not work with eCryptfs? Message-ID: References: <20230319.2139b35f996f@gnoack.org> <20230320.c6b83047622f@gnoack.org> <5d415985-d6ac-2312-3475-9d117f3be30f@digikod.net> <20230321172450.crwyhiulcal6jvvk@wittgenstein> <42ffeef4-e71f-dd2b-6332-c805d1db2e3f@digikod.net> Precedence: bulk X-Mailing-List: landlock@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: On 2023-03-23 18:05:38, Günther Noack wrote: > +ecryptfs mailing list FYI > > Just some additional data points on the Landlock/eCryptfs issues. > > On Tue, Mar 21, 2023 at 07:16:28PM +0100, Mickaël Salaün wrote: > > On 21/03/2023 18:24, Christian Brauner wrote: > > > On Tue, Mar 21, 2023 at 05:36:19PM +0100, Mickaël Salaün wrote: > > > > There is an inconsistency between ecryptfs_dir_open() and ecryptfs_open(). > > > > ecryptfs_dir_open() actually checks access right to the lower directory, > > > > which is why landlocked processes may not access the upper directory when > > > > reading its content. ecryptfs_open() uses a cache for upper files (which > > > > could be a problem on its own). The execution flow is: > > > > > > > > ecryptfs_open() -> ecryptfs_get_lower_file() -> ecryptfs_init_lower_file() > > > > -> ecryptfs_privileged_open() > > > > > > > > In ecryptfs_privileged_open(), the dentry_open() call failed if access to > > > > the lower file is not allowed by Landlock (or other access-control systems). > > > > Then wait_for_completion(&req.done) waits for a kernel's thread executing > > > > ecryptfs_threadfn(), which uses the kernel's credential to access the lower > > > > file. > > > > > > > > I think there are two main solutions to fix this consistency issue: > > > > - store the mounter credentials and uses them instead of the kernel's > > > > credentials for lower file and directory access checks (ecryptfs_dir_open > > > > and ecryptfs_threadfn changes); > > > > - use the kernel's credentials for all lower file/dir access check, > > > > especially in ecryptfs_dir_open(). > > > > > > > > I think using the mounter credentials makes more sense, is much safer, and > > > > fits with overlayfs. It may not work in cases where the mounter doesn't have > > > > access to the lower file hierarchy though. > > > > > > > > File creation calls vfs_*() helpers (lower directory) and there is not path > > > > nor file security hook calls for those, so it works unconditionally. > > > > > > > > From Landlock end users point of view, it makes more sense to grants access > > > > to a file hierarchy (where access is already allowed) and be allowed to > > > > access this file hierarchy, whatever it belongs to a specific filesystem > > > > (and whatever the potential lower file hierarchy, which may be unknown to > > > > users). This is how it works for overlayfs and I'd like to have the same > > > > behavior for ecryptfs. > > > > > > So given that ecryptfs is marked as "Odd Fixes" who is realistically > > > going to do the work of switching it to a mounter's credentials model, > > > making sure this doesn't regress anything, and dealing with any > > > potential bugs caused by this. It might be potentially better to just > > > refuse to combine Landlock with ecryptfs if that's possible. > > There is now a patch to mark it orphaned (independent of this thread): > https://lore.kernel.org/all/20230320182103.46350-1-frank.li@vivo.com/ I have little time to devote to eCryptfs these days. I'm not sure it needs to be fully orphaned but I think deprecation and marking for removal is the responsible thing to do. > > If Tyler is OK with the proposed solutions, I'll get a closer look at it in > > a few months. If anyone is interested to work on that, I'd be happy to > > review and test (the Landlock part). > > I wonder whether this problem of calling security hooks for the > underlying directory might have been affecting AppArmor and SELinux as > well? There seem to be reports on the web, but it's possible that I > am misinterpreting some of them: Yes, this eCryptfs design problem is common for other LSMs, as well. Tyler > > https://wiki.ubuntu.com/SecurityTeam/Roadmap > mentions this "unscheduled wishlist item": > "eCryptfs + SELinux/AppArmor integration, to protect encrypted data from root" > > https://askubuntu.com/a/1195430 > reports that AppArmor does not work on an eCryptfs mount for their use case > "i tried adding the [eCryptfs] source folder as an alias in apparmor and it now works." > > —Günther > > --