hayali

Port of OpenBSD's signify to Rust.

cargo install syd-tui

This seems to be mostly useless ai hype. Firstly it's quite impolite to assume all open sources projects are hosted on github/gitlab. That said, I uploaded sydbox.git temporarily to gitlab to have it scanned. It took 10 minutes to scan the whole project and it found a single vulnerability "RCE: IRC Message Command Execution Bypass" in file dev/bot.py which is our IRC script to run commands on the CTF server. Hilarious! Please do better :)

Emacs turns into Dangerzone! syd'em all! syd'em no regrets!

Updated sydbox to 3.35.0: hardened Landlock, empty mount namespaces using pivot_root and root:tmpfs a la bubblewrap, many bug fixes thx to LTP, many bug/portability fixes thx to Alpine Linux folks. New utilities syd-fd and syd-x. See the release mail for more information! syd'em all!

Scroll down a bit for the video that was just uploaded.

Here is a snapshot from the first ever server in the observable universe running Hardened Exherbo, https://0x0.st/8Z3h.png, which displays a very interesting and afaik novel usecase of notify action. if you read seccomp-unotify(2) and linux kernel docs it'll go telling you about how to run "higher privileges" in the handler process (such as mount, finit_module fancy for containers), however here we do _exactly_ the opposite (because why not), as you may easily observe the threads "syd_emu" running the syscalls are running as nginx user, however the "nginx master process" which is sandboxed by syd is still running as root (it spawns new workers who change uid, dont ask me why), so e.g. if you compromise the nginx master and run a syscall, it'll run as nginx user in a syd_emu thread anyhow. this we call SafeSetID (like that of linux kernel), i plan to do more in the future, imagine syd_emu threads are processes that're fork+execed with different address spaces with the sandbox policy shared behind a memfd that's sealed for write on sandbox getting locked.

Finally, this nginx serves https://hexsys.org atm from which you'll hopefully and eventually download iso's one day ;) So far I have sydboxed dhcp, rsyslog and ntpd, stay tuned!

better go for the latest version syd-3.32.0 which I've released shortly after fosdem. This release (hopefully) finishes the sandbox categorization work, check out https://man.exherbolinux.org/syd.7.html#SANDBOXING if you know about OpenBSD pledge(2), you'll feel mostly at home ;)

In this talk, I will introduce Syd, a GPL-3 licensed, rock-solid application kernel designed for sandboxing applications on Linux systems (version 5.19 and above). Over the past 16 years, Syd has evolved from a tool used within Exherbo Linux to detect package build mishaps into a robust security boundary for applications. The recent rewrite in Rust leverages modern Linux APIs such as seccomp-unotify(2), openat2(2), and pidfd_getfd(2) to eliminate time-of-check to time-of-use (TOCTTOU) vulnerabilities, which is essential for building a secure sandbox.

Nipped in the bud? Back to the roots!

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!

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.

slight correction, it's "pandora profile -mtrace/allow_unsafe_memory:1 firefox", as firefox by default uses JIT which needs WX memory.

Thank you for your kind words. As the author of syd and an Exherbo developer, I am working on a sibling distro called "Hardened Exherbo": https://hexsys.org. The idea is to contain all service daemons with Syd. I don't have much to show yet but I have successfully contained some daemons:

1. rsyslog: https://gitlab.exherbo.org/exherbo/arbor/-/blob/hex/packages...

2. openntpd: https://gitlab.exherbo.org/exherbo/arbor/-/blob/hex/packages...

3. nginx: https://gitlab.exherbo.org/exherbo/net/-/blob/hex/packages/w...

rsyslog and openntpd profiles may be slightly outdated. I am particularly proud about the nginx profile, it demonstrates many things above all SafeSetID and Binary verification. Note, nginx profile is only configured for static file serving, if you have app servers you're gonna have to allow them as well.

Syd has a trace mode when the access violations are only logged and allowed. The utility Pandora uses this mode to provide a learning mode. You can read more about pandora here: https://crates.io/crates/pandora_box

Pandora is really nice, it'll trim too long paths turning them into globs and calculate checksums for all the binaries and libraries used and invoking it is as easy as e.g. "pandora profile firefox".

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.

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