TOCTOU-free exec(), chdir(), open() with O_PATH sandbox emulation support?

TOCTOU-free exec(), chdir(), open() with O_PATH sandbox emulation support?

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 2216 bytes --]

Hi,

Ali Polatel <alip@chesswob.org> opened feature request bug on Bugzilla
regarding TOCTOU-free sandbox emulation support [1]. He wrote:

> Thanks to the addition of seccomp_addfd, now it is possible to emulate a vast number of system calls to achieve a TOCTOU-free sandbox in userspace. There're however three exceptions to this:
> 1. exec family calls cannot be emulated so a sandbox disallowing exec calls has no choice but to continue the exec call in sandbox process allowing TOCTOU.
> 2. chdir family calls cannot be emulated so a sandbox disallowing chdir calls to hide paths has no choice but to continue the chdir call in sandbox process allowing TOCTOU.
> 3. open calls with the O_PATH flag cannot be emulated (addfd returns EBADF on o_path fds) again a sandbox disallowing open calls with O_PATH flag to hide paths has no choice but to continue the open call in sandbox process allowing TOCTOU.
> 
> It'd be awesome for the kernel to provide TOCTOU-free ways to sandbox these three cases.
> 
> For a bit of context, I am the author of syd, a seccomp and landlock based application sandbox with support for namespaces, you can read here about why this feature request is relevant and more: http://man.exherbolinux.org/syd.7.html
> 
> To quote the relevant bit from the manual page:
>> BUGS
>> 
>> In the operation of syd, certain system calls are not fully emulated due to seccomp(2) limitations, resulting in the sandbox process continuing these calls directly. These include execve(2), execveat(2) for execution, chdir(2), fchdir(2) for directory changes, and open(2) operations with O_PATH flag. Consequently, this behavior exposes vulnerabilities to time-of-check to time-of-use attacks, allowing for the circumvention of Exec Sandboxing to execute denylisted paths, the bypass of Stat Sandboxing for unauthorized directory access without disclosing directory contents (owing to getdents(2) call emulation), and the detection of hidden files without revealing file metadata, as stat(2) calls are emulated.

Is the feature request viable/realistic?

Thanks.

[1]: https://bugzilla.kernel.org/show_bug.cgi?id=218501

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: TOCTOU-free exec(), chdir(), open() with O_PATH sandbox emulation support?

[Ⓐlï P☮latel]

[-- Attachment #1.1: Type: text/plain, Size: 1218 bytes --]

On Thursday, February 22nd, 2024 at 07:41, Bagas Sanjaya <bagasdotme@gmail.com> wrote:

> Hi,
> 

> Ali Polatel alip@chesswob.org opened feature request bug on Bugzilla
> 

> regarding TOCTOU-free sandbox emulation support [1]. He wrote:
[snip]
> Is the feature request viable/realistic?
> 

> Thanks.
> 

> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=218501

Just close it as ENOTG**GLE. Sorry for the noise¹...

All of these have "safe" workarounds:
1. PTRACE_EVENT_EXEC can workaround the inability to emulate exec.
   That said, you can TOCTOU scripts (because binfmt) but not ELFs!
   Just denylist the interpreters or W^X your FS like a chad or wait
   for O_MAYEXEC to happen if you care that much really.
2. Turn O_PATH to O_RDONLY and noone will know (pinky swear). You get to
   updoot access times but who cares if the alternative is unsafe?
3. Apparently, chdir is not seen as security critical² so why bother?

> --
> An old man doll... just what I always wanted! - Clara

¹: you cannot cover the sun with a sieve,
gv*sor is a joke: https://mastodon.online/@alip/113028762062293426
²: https://www.openwall.com/lists/oss-security/2024/05/20/1

--  
-Ⓐlïp.

[-- Attachment #1.2: publickey - alip@chesswob.org - 0x55838BF3.asc --]
[-- Type: application/pgp-keys, Size: 1751 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 509 bytes --]