Bug#1082001: linux-image-6.1.0-25-amd64: TOMOYO LSM rejects execveat(AT_EMPTY_PATH) inside chroot

[Salvatore Bonaccorso <carnil@debian.org>]

Control: forwarded -1 https://osdn.net/projects/tomoyo/lists/archive/users-en/2024-September/000765.html

Hi,

On Tue, Sep 24, 2024 at 01:28:19AM +0200, Ben Hutchings wrote:
> Control: tag -1 upstream
> 
> On Tue, 2024-09-17 at 01:45 +0200, Alfred Agrell wrote:
> > Package: src:linux
> > Version: 6.1.106-3
> > Severity: normal
> > X-Debbugs-Cc: blubban@gmail.com
> > 
> > Dear Maintainer,
> > 
> > Please run the following program (as root, so the chroot succeeds):
> > 
> > 
> > #define _GNU_SOURCE
> > #include <unistd.h>
> > #include <fcntl.h>
> > #include <stdio.h>
> > 
> > int main(int argc, char** argv)
> > {
> >         chdir("/lib/");
> >         if (chroot("/lib/") != 0)
> >                 perror("chroot (needs root)");
> >         execveat(open("./x86_64-linux-gnu/ld-linux-x86-64.so.2", O_RDONLY), "", NULL, NULL, AT_EMPTY_PATH);
> >         perror("execveat");
> > }
> [...]
> 
> When you pass an fd other than AT_FDCWD to execveat(), the fd and
> filename are translated internally to a filename starting with
> "/dev/fd/".  It's noted in the manual page that this affects the way
> script interpreters are called.  Another consequence is that when
> TOMOYO tries to look up that filename it finds that it does not exist.
> I verified that if /dev and /proc are mounted in the chroot your test
> program works.
> 
> This isn't a high priority for us, but if you report this upstream it
> might be fixed.  You'll need to subscribe to the TOMOYO mailing list at
> <https://lists.osdn.me/mailman/listinfo/tomoyo-users-en> and then send
> your report there.

This was reported upstream at
https://osdn.net/projects/tomoyo/lists/archive/users-en/2024-September/000765.html

Regards
Salvatore