From 9559682f5c1b6bfdbeb202e96de64a7324f233fe Mon Sep 17 00:00:00 2001 From: Liav A Date: Fri, 11 Nov 2022 01:58:35 +0200 Subject: [PATCH] Kernel: Disallow jail creation from a process within a jail We now disallow jail creation from a process within a jail because there is simply no valid use case to allow it, and we will probably not enable this behavior (which is considered a bug) again. Although there was no "real" security issue with this bug, as a process would still be denied to join that jail, there's an information reveal about the amount of jails that are or were present in the system. --- Kernel/Syscalls/jail.cpp | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/Kernel/Syscalls/jail.cpp b/Kernel/Syscalls/jail.cpp index 3ac5453106..68497bf515 100644 --- a/Kernel/Syscalls/jail.cpp +++ b/Kernel/Syscalls/jail.cpp @@ -25,9 +25,17 @@ ErrorOr Process::sys$jail_create(Userspacelength() > jail_name_max_size) return ENAMETOOLONG; - auto jail = TRY(JailManagement::the().create_jail(move(jail_name))); - params.index = jail->index().value(); - + params.index = TRY(m_attached_jail.with([&](auto& my_jail) -> ErrorOr { + // Note: If we are already in a jail, don't let the process to be able to create other jails + // even if it will not be able to join them later on. The reason for this is to prevent as much as possible + // any info leak about the "outside world" jail metadata. + if (my_jail) + return Error::from_errno(EPERM); + auto jail = TRY(JailManagement::the().create_jail(move(jail_name))); + return jail->index().value(); + })); + // Note: We do the copy_to_user outside of the m_attached_jail Spinlock locked scope because + // we rely on page faults to work properly. TRY(copy_to_user(user_params, ¶ms)); return 0; }