[PATCH] tomoyo: fallback to realpath if symlink's pathname does not exist

Alfred Agrell blubban at gmail.com
Wed Sep 25 12:49:59 UTC 2024


Hello

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 <blubban at gmail.com>
> Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082001
> Fixes: 51f39a1f0cea ("syscalls: implement execveat() system call")
> Signed-off-by: Tetsuo Handa <penguin-kernel at I-love.SAKURA.ne.jp>
> ---
> 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. */



More information about the Linux-security-module-archive mailing list