Bug#1082001: linux-image-6.1.0-25-amd64: TOMOYO LSM rejects execveat(AT_EMPTY_PATH) inside chroot
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
Reply to: