ostree VS bubblewrap

Ansible makes mutable changes to the OS, task by task.

Nix is immutable. A new change is made entirely new, and only after the build is successful, all packages are "symlinked" to the current system.

Fedora Silverblue is based on ostree [1]. It works similarly like git, but on your root tree. But it requires you to reboot the whole system for the changes to take effect. Since Nix is just symlinked packages, you don't need to reboot the system.

More detailed explanation here [2].

[1]: https://github.com/ostreedev/ostree

[2]: https://dataswamp.org/~solene/2023-07-12-intro-to-immutable-...

This one is for the ostree bug currently ongoing: https://github.com/ostreedev/ostree/issues/2900

This sounds related to the ostree bug.

I definitely agree that immutability offers considerable value in regards to improving security. But arguably it's insufficient to pull the win over mutable Fedora due to the losses caused by the inability to install the kernel-hardened package and the lack of UKI (Unified Kernel Image) support.

Other hardening guides mention a Unified Kernel Image as another measure to further improve security. Unfortunately, once more, this is (currently) not supported on Fedora Silverblue. I haven't seen it being done on openSUSE Aeon either. Though, once again, I'd love to be corrected!

The fedora crew is working on it through ostree though, so both fedora Silverblue and flatpak will be getting it (as well as true immutability) in the future: https://github.com/ostreedev/ostree/issues/2867

Aside from what has already been mentioned, Unified Kernel Image isn't supported (yet).

Ariadne Conill, Founder and Distinguished Engineer at Edera, highlighted the necessity for a new low-level container runtime in a recent blog post. Existing solutions like Bubblewrap and util-linux’s unshare rely heavily on complex command-line interfaces or lack the required programming control, making them error-prone. In contrast, high-level solutions like Kubernetes' Container Runtime Interface (CRI) abstract too much for low-level management, creating a gap that Styrolite aims to fill.

Another thing to look at is bubblewrap (https://github.com/containers/bubblewrap), which is what implements the sandboxing in Flatpak. It's handy on it's if you want to run a command from your host in a particular sandbox as kind of a one-off.

> Not requiring the cooperation of developers to opt-in, for starters.

True, meaningful in the general case, and completely irrelevant in this particular case, which started with specifically the question of OpenBSD applying the protection in question to its own base system. I actually agree that being able to externally impose a sandbox is super useful, but self-imposed restrictions are perfectly applicable in this usecase.

> You really think pledge and unveil are equivalent to sandboxing? Can you refer to any sandboxing solution or technologies that limit themselves to restricting syscalls and hiding file paths? Unveil is a lot more useful as a component in sandboxing, I'll give you that.

I think that pledge and unveil are a type of sandboxing, certainly. And... I'm struggling to think of any sandboxing tech that does anything but limit syscalls and filesystem access. After rereading https://github.com/containers/bubblewrap?tab=readme-ov-file#... a bit, I suppose there's a case for being able to change what a sandboxed process can see rather than only masking (ex. PID 1 is a different process inside and outside the sandbox), but that strikes me as a slight variation rather than a fundamental difference in what is or isn't a "sandbox" per se. Likewise, I could see an argument that OpenBSD's approach is coarser than it could be; ex. I think you could restrict a Linux process to keep your real user and be able to read files but not write them even though they're owned by your user and are 644, but that's more of a convenience thing than a true fundamental difference - an OpenBSD process could open files in read mode, keep the socket open, and then pledge away open() altogether which gives you the same outcome with more legwork.

As an example we will look at man 1 bwrap. Bubblewrap allows us to sandbox an application, not too dissimilar to docker. Flatpaks use bubblewrap as part of their sandbox. Bubblewrap can optionally take in a list of syscalls to filter. The filter is expressed as a BPF(Berkley Packet Filter program - remember when I said docker gives you a friendlier interface to seccomp?) program. Below is a short program that defines a BPF program that can be passed to an application using bwrap that lets us log all the sycalls the application makes to syslog.

Nothing nix specific but you may be interested in https://github.com/containers/bubblewrap

Recently, I came across Chainguard and wrote the article How to build Docker Images with Melange and Apko. As a fervent supporter of Kubernetes and GitLab CI, I was eager to experiment with building images using Melange in this particular setup. GitLab's shared Runners work seamlessly with Bubblewrap, eliminating the need for additional configurations. This post is intended for enthusiasts like myself, interested in hosting their own Kubernetes Runners and leveraging the Kubernetes Runner Type of Melange.