Can we investigate the syd project?

[osevan]

Maybe some mitigations techniques we can take and reproduce in firejail.

https://rentry.co/DSRsecuritycoursepart2#syd-the-perhaps-most-sophisticated-sandbox-for-linux

https://man.exherbolinux.org/syd-mdwe.1.html#COMPARISON_TO_PaX

All ideas and comments are welcome

[rusty-snake]

syd ...

• has an unclear/inscrutable security model
• does risky things that are likely to blow up in your face at some conditions
• is vulnerable to TOCTOU
• has half / incomlete "security" features
• protects against things fixed in the kernel a long time ago
• gives you a false sense (felling) of security
• has a good marketing

Can we still learn something from it? Yes, we can learn about

• more ideas for seccomp, but this is not limited to syd, other projects like with heavy use of seccomp like all the attemts for an seccomp based pledge API for linux (https://github.com/jart/cosmopolitan/blob/master/libc/calls/pledge-linux.c, probably one of the best ones).
• newer kernel features, but this is not limited to syd, other projects with a focus on newer kernels will use the same new features _{(not linking to my projects here)}

[alip]

With all due respect, I want to say this is an inaccurate assessment:

syd ...

* has an unclear/inscrutable security model

http://man.exherbolinux.org/syd.7.html#SECURITY

* does risky things that are likely to blow up in your face at some conditions

I disagree, please can you give me an example so we can discuss?

* is vulnerable to TOCTOU

No it's not, https://git.sr.ht/~alip/syd/tree/main/item/doc/toctou-or-gtfo.md

* has half / incomlete "security" features

I disagree, please can you give me an example so we can discuss?

* protects against things fixed in the kernel a long time ago

I disagree. E.g. MDWE is also applied by systemd.

* gives you a false sense (felling) of security

* has a good marketing

Syd is a project that is 16 years old and suddenly we have good marketing because some random person decided to list its features? LMAO.

[alip]

• protects against things fixed in the kernel a long time ago

Here, let me give you two recent examples:

1. CVE-2023-38408: Syd is not affected because we enforce non-executable stack restriction at mmap(2) boundary to mitigate exploits that change stack to executable by dlopen(3)'ing a library with executable stack. SELinux and HardenedBSD have similar mitigations in place to defend against this.
2. CVE-2024-42318: Syd is not affected because we deny the keyctl(2) system call by default. Secure defaults matter! FireJail also uses Landlock, you could use a similar mitigation ;)

[rusty-snake]

Trying to prioritize to reply to at least some points ...

The it's a "dont tool" assessment is the one I came to the last time I looked at syd. If that's not the case and I have a new tool in my toolbox, I'll be happy.

* does risky things that are likely to blow up in your face at some conditions

I disagree, please can you give me an example so we can discuss?

Re-implementing kernel logic in particular permissions related checks.
Something that I consider to never be properly implemented.

* is vulnerable to TOCTOU

No it's not, https://git.sr.ht/~alip/syd/tree/main/item/doc/toctou-or-gtfo.md

I admit that you put a lot of effort in finding workarounds for racy kernel APIS and welcome documenting the workarounds and the still open limitations. However multiple places talk about being vulnerable to TOCTOU (example) and even your link concludes with

On the other hand, sydbox, with sydbox-3, attempts to function as a security boundary with more advanced features and mitigations against TOCTOU (Time-of-Check to Time-of-Use) attacks. Despite these efforts, both sandboxes are still vulnerable to certain TOCTOU exploits due to inherent limitations in the ptrace(2) and seccomp(2) frameworks, which requires some system calls to be resumed within the sandbox process.

* protects against things fixed in the kernel a long time ago

"Null Address Mapping Prevention"

I'm not aware of a way to mmap below vm/mmap_min_addr.

[alip]

Trying to prioritize to reply to at least some points ...

First of all, thank you very much for taking the time to answer.

The it's a "dont tool" assessment is the one I came to the last time I looked at syd. If that's not the case and I have a new tool in my toolbox, I'll be happy.

I understand that. Syd as a security boundary is relatively new.

* does risky things that are likely to blow up in your face at some conditions

I disagree, please can you give me an example so we can discuss?

Re-implementing kernel logic in particular permissions related checks. Something that I consider to never be properly implemented.

I agree and being 100% compatible is a difficult task. That said, we're aware of the risk and trying really hard to ensure compatibility. Exherbo is a Linux distribution with package testing on, so we run all package tests under Syd which made us catch and fix a lot of compatibility issues. Moreover we run a random selection of gnulib tests in our CI on every push.

That said, there's also the advantage that it gives you more power. Simple example, you can do trace/force_umask:7177 to stop the user from ever creating executable or S{U,G}ID files, or you can "mask" files by returning a fd to /dev/null each time they're opened. A more sophisticated example is Crypt Sandboxing which offers simple transparent encryption using the kernel API. Some of this is possible without syscall emulation but some of it is not. This shows the place of Syd among sandboxes: It does more than a typical sandbox does, has comparably more overhead but in return the user gets more control. I believe Syd will be a nice alternative for people's sandboxing toolbox along with Firejail, Bubblewrap etc.

* is vulnerable to TOCTOU

No it's not, https://git.sr.ht/~alip/syd/tree/main/item/doc/toctou-or-gtfo.md

I admit that you put a lot of effort in finding workarounds for racy kernel APIS and welcome documenting the workarounds and the still open limitations. However multiple places talk about being vulnerable to TOCTOU (example) and even your link concludes with

On the other hand, sydbox, with sydbox-3, attempts to function as a security boundary with more advanced features and mitigations against TOCTOU (Time-of-Check to Time-of-Use) attacks. Despite these efforts, both sandboxes are still vulnerable to certain TOCTOU exploits due to inherent limitations in the ptrace(2) and seccomp(2) frameworks, which requires some system calls to be resumed within the sandbox process.

Yes, but you're taking this paragraph out of context and saying "Syd is vulnerable to TOCTOU" which is a completely incorrect generalization. The only syscall handler that is vulnerable to TOCTOU atm, is chdir. And this vulnerability exists not just in Syd but in Landlock too (you can chdir into denylisted directories, however you cannot do any further than that, see this bug for more info: https://bugzilla.kernel.org/show_bug.cgi?id=218501). I'm proud to say we've completely mitigated all other TOCTOU issues and we have tests to verify.

* protects against things fixed in the kernel a long time ago

"Null Address Mapping Prevention"

I'm not aware of a way to mmap below vm/mmap_min_addr.

What if the attacker could change the sysctl to 0? ;) Of course this is unlikely and yes, this is a fair critic. However I should say this mitigation is really small and practically zero-cost. In general, when it comes to mitigations with minimal cost, our approach is "the more layers, the merrier.". We believe in defense in depth. I'll go ahead and update the manual page to mention vm/mmap_min_addr to avoid the confusion though. Thank you very much.