Syd the perhaps most sophisticated sandbox for Linux

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.

Huh. Does anyone know how it works without additional privileges?

I ran syd as a normal user on my system and it blocked network calls. Does it fall back to ptrace? I don't think my user has the ability to create network namespaces.

edit: Ah, ok. There's a little more here: https://gitlab.exherbo.org/sydbox/sydbox/-/blob/main/doc/toc.... And the readme does mention ptrace. Would be great to understand how to introspect what this is using and when. ie: in some cases I might not be able to tolerate the performance penalty of ptrace.

edit2: ah ok wayyyy more info here: https://man.exherbolinux.org/syd.1.html

and benchmarks: https://man.exherbolinux.org/syd.1.html#BENCHMARKS

So it is slower, but much faster than I would have expected. Wild.

I found this document hard to follow. Perhaps the repo is more informative: https://gitlab.exherbo.org/sydbox/sydbox

That page looks like a madman's ramblings. Anyone has a comparison with bubblewrap, which is what I'm current using?

> Syd is a user space wrapper

This sentence does not give me confidence. A general purpose sandbox should be implemented in the kernel. The kernel syscall interface will always remain available regardless of any sandbox that has been implemented in user space.

EDIT (to answer a few of the replies here):

The description lacks details so it's not entirely clear how Syd is intended to be used or who its target audience is. If this is intended for a security conscious user to wrap their own executables, similar to Firejail, I guess this serves a purpose but I would certainly hesitate to suggest that it is the "most sophisticated sandbox for Linux". We already have kernel-based SELinux, AppArmor, other LSMs and grsecurity which can ensure that every single executable will run in a sandbox regardless of the experience of the end-user, something a user space wrapper cannot achieve. It's not about whether or not it uses kernel facilities but about ensuring that absolutely everything will be sandboxed.

sort of reminds me of https://github.com/google/gvisor, re syscall interception and checking. gvisor had some significant performance impacts for io/syscall heavy workloads, but potentially seccomp/bpf could do better albeit that's mostly filtering/transform on param re more minimal touchpoint.

Would love to see recording of the lectures I assume this is supporting material for.

Yes