mirror of
https://github.com/RGBCube/serenity
synced 2025-07-25 18:17:44 +00:00
Kernel: Disallow executing SUID binaries if process is jailed
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:
parent
0e010790a4
commit
e598f22768
4 changed files with 23 additions and 2 deletions
|
@ -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
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue