> Syd also blocks executable+anonymous memory
> 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 and Force Sandboxing to execute denylisted paths, the bypass of Stat Sandboxing for unauthorised 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
> As of version 3.19.0, Syd turns the "O_PATH" flag in open(2) system call arguments to the "O_RDONLY" flag and emulates the system call as usual which avoids the TOCTOU vector
When you see hacks piled on top of hacks this way, there's usually something wrong with the fundamental architecture of the system. I think I'd rather just use bwrap, a LSM, or a VM.
That said, there are a few nuggets of good ideas in here, e.g. disabling TIOCSTI and rate-limiting launches of programs that die with SIGSEGV. These enhancements should be in the core system, not a launcher utility.