From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) (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 570B179CE for ; Mon, 27 Mar 2023 21:01:21 +0000 (UTC) Received: by mail-lj1-f181.google.com with SMTP id h9so10461038ljq.2 for ; Mon, 27 Mar 2023 14:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679950879; 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=fgkDasYPMzaBbgNL+DqfU6jbIrTRjZPA7BY9S1xa4jY=; b=buhGNkCzJU577oYyFubhiOOgwekEvLD3Exu1r4Ax/65utihU2sccc0WWlkHRy3ZUt/ 0Z425iEFB/QHddim7/J2/y8lxK3lks42lOj3HgCWHJOoAvjDpndZvhAjCWxf21wl32BT 6zkjh5l84C1u5Pmt9+LBnli3V7fEpc3pqu+D8IllrCl5LqfwrY3d6Vrl3b02VbTyEhp5 JHGYFyXabsu6XtM8xQ6qtNm2kLC77gE7ObrhXuarKoWKZaAZExtqwGpTAsNsR7Uw4xsz 59AidY9SjEnLweOSNLxQL2d//2H43cbZA4IWWBTAnMXV+7kb2ww00gFSoIvLp0zJyquQ junQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679950879; 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=fgkDasYPMzaBbgNL+DqfU6jbIrTRjZPA7BY9S1xa4jY=; b=v5S3p12gZjZjgTmngvuFLPjoE41bvEmL2PWdxN8D79ZzLIZNwbF+/8wg6G9LPpACn/ xV+HNizaafMlmMm0jDBRF54RZviDmDB92/Rn2S8DplHbTqCIHXOSFbvNCKlZGp5XDkM9 EOWmpd5+Y2n63Gjszn8XGSM6VUM2GWJQOxkt/klDzV3kfvylBkEci5ZxXDko2gQTq/3K zEZnPzebjCdR4VUhC1LP2rIgQPHEHz3igsQxFcxbeGL47mTsNgX6FnKdroqmtbeoPUm7 JqJZ6SM6HFvJl1U/E6odlAQhzxFlQZ8H7dUBkKYB3AtstPdKrO9rZO+TryrIqUXkgWqg q9bA== X-Gm-Message-State: AAQBX9eOAO2HT8mvMP/SJJAFi54/qdURdb7InpdPMALwtN1iFUTTLCQe 6HSBmho9Trz1Ym1D9mk7ZXg= X-Google-Smtp-Source: AKy350bdQOG5ybFFh9LJzYSc6zXxEoX9RGfivIawJ42vOrw8T5lGt3DWwetPCE0dzHm+3bb6uHyX4Q== X-Received: by 2002:a2e:8785:0:b0:2a5:ff82:178a with SMTP id n5-20020a2e8785000000b002a5ff82178amr350287lji.33.1679950879210; Mon, 27 Mar 2023 14:01:19 -0700 (PDT) Received: from localhost ([2a02:168:633b:1:9d6a:15a4:c7d1:a0f0]) by smtp.gmail.com with ESMTPSA id r10-20020a2eb60a000000b002945b851ea5sm4784219ljn.21.2023.03.27.14.01.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Mar 2023 14:01:18 -0700 (PDT) Date: Mon, 27 Mar 2023 23:01:13 +0200 From: =?iso-8859-1?Q?G=FCnther?= Noack To: =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= Cc: Tyler Hicks , Christian Brauner , landlock@lists.linux.dev, linux-security-module , Linux-Fsdevel , Al Viro Subject: Re: Does Landlock not work with eCryptfs? Message-ID: <20230327.bddbc828c0ec@gnoack.org> 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: Hello! On Sun, Mar 26, 2023 at 11:19:19PM +0200, Mickaël Salaün wrote: > On 24/03/2023 23:53, Tyler Hicks wrote: > > On 2023-03-21 19:16:28, Mickaël Salaün wrote: > > > 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 am alright with using the mounter creds but eCryptfs is typically > > mounted as root using a PAM module so the mounter is typically going to > > be more privileged than the user accessing the eCryptfs mount (in the > > common case of an encrypted home directory). > > > > But, as Christian points out, I think it might be better to make > > Landlock refuse to work with eCryptfs. Would you be at ease with that > > decision if we marked eCryptfs as deprecated with a planned removal > > date? > > The only way to make Landlock "refuse" to work with eCryptfs would be to add > exceptions according to the underlying filesystem when creating rules. > Furthermore, to be consistent, this would need to be backported. I don't > want to go in such direction to fix an eCryptfs issue. Here is an example where the Landlock LSM can't detect eCryptfs: mkdir -p /foo/bar/baz /foo/secret landlock-restrict -ro / -rw /foo/bar -- /bin/bash # finally, in a different terminal: mount.ecryptfs /foo/secret /foo/bar/baz The shell is supposed to have access to /foo/bar and everything below it, but at the time of creating the Landlock ruleset, it can't tell yet that this directory will contain an eCryptfs mount later. Admittedly, the example is obscure, but it's strictly speaking supposed to work according to the Landlock documentation. (Only the landlocked process can't use mount(2) any more, but other processes still can.) Note on the side: Even when mount.ecryptfs happens before the Landlock restriction, the Landlock LSM would have to traverse the existing mounts to see if there is an eCryptfs mount *below* /foo/bar. > Doing nothing would go against the principle of least astonishment because > of unexpected and inconsistent behavior when using Landlock with eCryptfs. > Indeed, Landlock users (e.g. app developers) may not know how, where, and on > which kernel their sandboxed applications will run. This means that at best, > developers will (potentially wrongly) check if eCryptfs is available/used > and then disable sandboxing, and at worse the (opportunistically) sandboxed > apps will break (because of denied access). In any case, it goes against > user's interests. I agree, I also believe that a kernel-side fix is needed. I don't think this is feasible to do in a good way in userspace, even if we want to resort to "falling back to doing nothing" in best effort mode if eCryptfs file hierarchies are affected. I have pondered these userspace approaches how to detect eCryptfs, but they are both lacking: * Looking for eCryptfs in /proc/mounts might not work if we are layering multiple Landlock rulesets. * stat(2) also does not give away whether a file is on eCryptfs (the device number is just a generic kernel internal one) Finally, it all falls apart anyway if we want to support the case where eCryptfs is mounted after enabling the sandbox. (Obscure, but possible.) > Even if eCryptfs is marked as deprecated, it will be available for years (a > lot for LTS) and (legitimate) bug reports will keep coming. > > Instead, I'd like to fix the eCryptfs inconsistent behavior (highlighted by > Landlock and other LSMs). I think it's worth trying the first proposed > solution, which might not be too difficult to implement, and will get > eCryptfs closer to the overlayfs semantic. +1. As you also said: I think it's important to fix it in the LTS releases, so that we can tell people to use Landlock without having to think about these corner cases. –Günther