From: "Günther Noack" <gnoack3000@gmail.com>
To: "Mickaël Salaün" <mic@digikod.net>
Cc: Andrea Cervesato <andrea.cervesato@suse.com>, landlock@lists.linux.dev
Subject: Re: Help with LANDLOCK_ACCESS_FS_EXECUTE
Date: Wed, 17 Jul 2024 10:51:00 +0200 [thread overview]
Message-ID: <20240717.388d6f809b52@gnoack.org> (raw)
In-Reply-To: <20240701.Pe4zeeph4epo@digikod.net>
Hello!
(Re-sending this message from July 1st for the record, as it was
previously rejected by the mailing list and only went to the
discussion participants. The problem was resolved in the end.)
On Mon, Jul 01, 2024 at 05:16:19PM +0200, Mickaël Salaün wrote:
> On Mon, Jul 01, 2024 at 04:25:53PM +0200, Andrea Cervesato wrote:
> > Hi all,
> >
> > I'm actually writing a test for LANDLOCK_ACCESS_FS_EXECUTE flag in LTP [1].
> > The test is really simple: it applies the EXECUTE landlock rule inside a
> > folder and it verifies that a binary inside it can be executed.
> > A similar test applies the rule only to the specific binary and check again
> > its execution.
>
> Good to know you're working on that!
>
> >
> > But while I was writing the test, I encountered an issue with the specific
> > rule setup, since EACCES is raised unexpectedly during binary execution.
> > So I wrote a reproducer, assuming that LTP might be the issue, but it's not.
> > The reproducer actually shows that binary can't be executed after applying
> > the EXECUTE rule.
> >
> > I will attach the source code to this email. Can you please tell me if
> > there's something wrong with it?
>
> I guess the binary you're trying to execute is dynamically linked, which
> means that the kernel needs to open the related .so files on behalf of
> the calling (sandboxed) process, which means that
> LANDLOCK_ACCESS_FS_READ_FILE needs to be allowed on these files. You
> can use a static binary to avoid this kind of issue, or just not handle
> LANDLOCK_ACCESS_FS_READ_FILE.
I've tried this out, it seems that it actually needs both
LANDLOCK_ACCESS_FS_READ_FILE and LANDLOCK_ACCESS_FS_EXECUTE on that
file in order to execute it, even if the file is statically linked
(LDFLAGS=3D-stat= ic make landlock_exec).
Once you have execve(2) succeeding, it gets more complicated with
shared libraries in the mix. If you are looking to support something
like that, it helps to read the man page ld.so(8) to understand what
paths need to be whitelisted for shared libraries. The XDG Base
Directory specification can help with the location of config files. (
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.htm=
l).
Your program runs nicely under `strace -f`, which helps to debug the
exact place where it fails - I tend to use something like that as a
driver for making it work.
–-Günther
prev parent reply other threads:[~2024-07-17 8:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-01 14:25 Help with LANDLOCK_ACCESS_FS_EXECUTE Andrea Cervesato
2024-07-01 15:16 ` Mickaël Salaün
2024-07-17 8:51 ` Günther Noack [this message]
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=20240717.388d6f809b52@gnoack.org \
--to=gnoack3000@gmail.com \
--cc=andrea.cervesato@suse.com \
--cc=landlock@lists.linux.dev \
--cc=mic@digikod.net \
/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