[quotemstr]

This program seems fragile and too eager to break longstanding system ABI --- for example, silently turning O_RDWR into O_WRONLY, prohibiting PROT_EXEC on memfds, and, well,

> 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.

[hayali]

Imho, you're judging syd too harshly without really understanding it:

> for example, silently turning O_RDWR into O_WRONLY

This is only done for Crypt sandboxing and admittedly it's mostly aimed for encrypting small files that are rarely rewritten, such as config.

> prohibiting PROT_EXEC on memfds

Syd is secure by default and almost always gives you options to relax specific restrictions. For this one, you want: https://man.exherbolinux.org/syd.2.html#trace/allow_unsafe_m...

> Syd also blocks executable+anonymous memory

Same, can be disabled if not needed: https://man.exherbolinux.org/syd.2.html#trace/allow_unsafe_m...

> > 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

This is a kernel limitation and there's an open kernel bug to implement O_PATH similar to O_CLOEXEC: https://bugzilla.kernel.org/show_bug.cgi?id=218501

[hayali]

Also note, Syd has been used as Exherbo's default sandbox for 16 years now and Exherbo is a source-based distribution which enables package testing by default (we call them "build_options: recommended_tests"), and every package build/test failure that happens under sandbox but not without sandbox is considered a sydbox bug. We have fixed a lot over the years. Moreover, we have a CI task to run a random selection of a hundred gnulib tests (under 64-bit and 32-bit respectively, x86-64, x86, armv{8..7}) on each push. We can therefore proudly say that Syd is reliable when it comes to functional correctness.

[qznc]

So it really might be „the most sophisticated“ one. Unfortunately, for security we rather need simplicity than sophistication. There should be „obviously no errors“ instead of „no obvious errors“ to quote Hoare.

[hayali]

This one almost made me laugh. Syd is a _unikernel_ and as such much simpler in design than GVisor which is a full-blown user-space kernel.

[hayali]

Finally, you're recommending this to be in the kernel. I agree for the most part, however this should be as an extra layer. The more layers, the merrier! One known example is Dirty CoW which don't work under Syd or GVisor.

Also this, https://news.ycombinator.com/item?id=41005936, lulz!