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