RGBCube/serenity
1
Fork 0
mirror of https://github.com/RGBCube/serenity synced 2025-07-26 10:37:45 +00:00
Code Issues Activity Actions

Kernel: Disallow executing SUID binaries if process is jailed

Browse source 
Check if the process we are currently running is in a jail, and if that
is the case, fail early with the EPERM error code.

Also, as Brian noted, we should also disallow attaching to a jail in
case of already running within a setid executable, as this leaves the
user with false thinking of being secure (because you can't exec new
setid binaries), but the current program is still marked setid, which
means that at the very least we gained permissions while we didn't
expect it, so let's block it.
This commit is contained in:
Liav A 2022-12-23 13:51:47 +02:00 • committed by Brian Gianforcaro
parent 0e010790a4
commit e598f22768
4 changed files with 23 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

11
Kernel/Syscalls/jail.cpp
View file

@ -45,6 +45,17 @@ ErrorOr<FlatPtr> Process::sys$jail_attach(Userspace<Syscall::SC_jail_attach_para
VERIFY_NO_PROCESS_BIG_LOCK(this);
TRY(require_promise(Pledge::jail));
// NOTE: Because the user might run a binary that is using this syscall and
// that binary was marked as SUID, then the user might be unaware of the
// fact that while no new setuid binaries might be executed, he is already
// running within such binary so for the sake of completeness and preventing
// naive sense of being secure, we should block that.
TRY(with_protected_data([&](auto& protected_data) -> ErrorOr<void> {
if (protected_data.executable_is_setid)
return EPERM;
return {};
}));
auto params = TRY(copy_typed_from_user(user_params));
return m_attached_jail.with([&](auto& my_jail) -> ErrorOr<FlatPtr> {
// Note: If we are already in a jail, don't let the process escape it even if