From: "Mickaël Salaün" <mic@digikod.net>
To: "Günther Noack" <gnoack3000@gmail.com>
Cc: landlock@lists.linux.dev, Tyler Hicks <code@tyhicks.com>,
linux-security-module <linux-security-module@vger.kernel.org>,
Linux-Fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: Does Landlock not work with eCryptfs?
Date: Mon, 20 Mar 2023 18:21:13 +0100 [thread overview]
Message-ID: <5d415985-d6ac-2312-3475-9d117f3be30f@digikod.net> (raw)
In-Reply-To: <20230320.c6b83047622f@gnoack.org>
On 20/03/2023 18:15, Günther Noack wrote:
> Hello!
>
> On Sun, Mar 19, 2023 at 10:00:46PM +0100, Mickaël Salaün wrote:
>> Hi Günther,
>>
>> Thanks for the report, I confirm there is indeed a bug. I tested with a
>> Debian distro:
>>
>> ecryptfs-setup-private --nopwcheck --noautomount
>> ecryptfs-mount-private
>> # And then with the kernel's sample/landlock/sandboxer:
>> LL_FS_RO="/usr" LL_FS_RW="${HOME}/Private" sandboxer ls ~/Private
>> ls: cannot open directory '/home/user/Private': Permission denied
>>
>> Actions other than listing a directory (e.g. creating files/directories,
>> reading/writing to files) are controlled as expected. The issue might be
>> that directories' inodes are not the same when listing the content of a
>> directory or when creating new files/directories (which is weird). My
>> hypothesis is that Landlock would then deny directory reading because the
>> directory's inode doesn't match any rule. It might be related to the overlay
>> nature of ecryptfs.
>>
>> Tyler, do you have some idea?
>
> I had a hunch, and found out that the example can be made to work by
> granting the LANDLOCK_ACCESS_FS_READ_DIR right on the place where the
> *encrypted* version of that home directory lives:
>
> err := landlock.V1.RestrictPaths(
> landlock.RODirs(dir),
> landlock.PathAccess(llsys.AccessFSReadDir, "/home/.ecryptfs/gnoack/.Private"),
> )
>
> It does seem a bit like eCryptfs it calling security_file_open() under
> the hood for the encrypted version of that file? Is that correct?
Yes, that's right, the lower directory is used to list the content of
the ecryptfs directory:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/ecryptfs/file.c#n112
iterate_dir(lower_file, …)
next prev parent reply other threads:[~2023-03-20 17:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230319.2139b35f996f@gnoack.org>
2023-03-19 21:00 ` Does Landlock not work with eCryptfs? Mickaël Salaün
2023-03-20 17:15 ` Günther Noack
2023-03-20 17:21 ` Mickaël Salaün [this message]
2023-03-21 16:36 ` Mickaël Salaün
2023-03-21 17:24 ` Christian Brauner
2023-03-21 18:16 ` Mickaël Salaün
2023-03-23 17:05 ` Günther Noack
2023-03-24 22:45 ` Tyler Hicks (Microsoft)
2023-03-24 22:53 ` Tyler Hicks
2023-03-26 21:19 ` Mickaël Salaün
2023-03-27 21:01 ` Günther Noack
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5d415985-d6ac-2312-3475-9d117f3be30f@digikod.net \
--to=mic@digikod.net \
--cc=code@tyhicks.com \
--cc=gnoack3000@gmail.com \
--cc=landlock@lists.linux.dev \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).