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 <blub...@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-ker...@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. */

_______________________________________________
tomoyo-users-en mailing list
tomoyo-users-en@lists.osdn.me
https://lists.osdn.me/mailman/listinfo/tomoyo-users-en

Reply via email to