TOMOYO
ForkHello
The environment in which I discovered this issue is a homemade
sandboxing solution that chroots to an empty directory, and uses
seccomp-bpf SIGSYS to forward filesystem operations to the sandbox
manager process. The exec target is a statically linked binary
specifically designed for said sandbox.
I don't expect that exec of arbitrary programs will work (most of them
have .interp = /lib64/ld-linux-x86-64.so.2, which doesn't exist either),
but I do expect that this specific program works.
I don't know enough about the kernel to say anything about that patch;
if you say it works, I'll trust that. Thanks.
-- Alfred Agrell
On 2024-09-25 13:01, Tetsuo Handa wrote:
> Alfred Agrell found that TOMOYO cannot handle execveat(AT_EMPTY_PATH)
> inside chroot environment where /dev and /proc are not mounted, for
> commit 51f39a1f0cea ("syscalls: implement execveat() system call") missed
> that TOMOYO tries to canonicalize argv[0] when the filename fed to the
> executed program as argv[0] is supplied using potentially nonexistent
> pathname.
>
> Since "/dev/fd/<fd>" already lost symlink information used for obtaining
> that <fd>, it is too late to reconstruct symlink's pathname. Although
> <filename> part of "/dev/fd/<fd>/<filename>" might not be canonicalized,
> TOMOYO cannot use tomoyo_realpath_nofollow() when /dev is not mounted.
>
> Therefore, fallback to tomoyo_realpath_from_path() when
> tomoyo_realpath_nofollow() failed. This change makes TOMOYO unable to
> utilize argv[0] for controlling domain transitions for multi-call binaries
> (e.g. busybox), but this change would be better than failing to handle
> execveat(AT_EMPTY_PATH) inside chroot environment.
>
> Reported-by: Alfred Agrell <blubb****@gmail*****>
> Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082001
> Fixes: 51f39a1f0cea ("syscalls: implement execveat() system call")
> Signed-off-by: Tetsuo Handa <pengu****@I-lov*****>
> ---
> Alfred, what do you think? That commit mentioned
>
> This does however mean that execution of a script in a /proc-less
> environment won't work
>
> . Are you expecting that execution of non-scripts in a /dev-less and
> /proc-less environment work? I guess that majority of programs depend
> on /dev and /proc being mounted even inside chroot environment. But
> if you have programs intended to be executed in a /dev-less and
> /proc-less chroot environment, this patch should fix this problem...
>
> security/tomoyo/domain.c | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/security/tomoyo/domain.c b/security/tomoyo/domain.c
> index 90b53500a236..272e8474d15f 100644
> --- a/security/tomoyo/domain.c
> +++ b/security/tomoyo/domain.c
> @@ -723,10 +723,14 @@ int tomoyo_find_next_domain(struct linux_binprm *bprm)
> ee->r.obj = &ee->obj;
> ee->obj.path1 = bprm->file->f_path;
> /* Get symlink's pathname of program. */
> - retval = -ENOENT;
> exename.name = tomoyo_realpath_nofollow(original_name);
> - if (!exename.name)
> - goto out;
> + if (!exename.name) {
> + /* Fallback to realpath if symlink's pathname does not exist. */
> + retval = -ENOMEM;
> + exename.name = tomoyo_realpath_from_path(&bprm->file->f_path);
> + if (!exename.name)
> + goto out;
> + }
> tomoyo_fill_path_info(&exename);
> retry:
> /* Check 'aggregator' directive. */