Re: Help with LANDLOCK_ACCESS_FS_EXECUTE

Günther Noack <[email protected]> Wed, 17 Jul 2024 10:51:00 +0200
Newsgroups dev.linux.lists.landlock
Message-ID <[email protected]>
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