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
