Implement a ChromeOS' Crostini-like system

[Malom-ctrl]

ChromeOS has a linux apps sandboxing solution called Crostini.
It lets the user launch untrusted code in a completly safe manner being sure it cannot reach the host OS.
It's mainly used to launch GUI apps that then integrate perfectly with the host OS as if they were native apps.

I think this kind of feature would be huge to have on desktop linux. Users could install apps as usual, have those apps behave like native apps on their desktop, while in the meantime being completly sandboxed in a memory safe VM.

Now, that's easier said than done given that Crostini is made to work with the whole ChromeOS software stack and cannot just run on our typical linux distros.

So here is what i've brainstormed: (It's far from a real plan yet)

So Crostini has many moving parts (see: https://www.chromium.org/chromium-os/developer-library/guides/containers/containers-and-vms/).

Crosvm

Crostini creates very tiny VMs that can boot incredibly fast and use very low amount of RAM using their own Virtual Machine Monitor called Crosvm, It's basically a simpler QEMU written in memory safe language so the attack surface is way smaller. (see: https://crosvm.dev/book/)

We could use Firecracker for the same effect, it's a fork of Crosvm from AWS that keeps the same advantages and is designed to run on typical linux distros.
Firecracker is already in the Fedora repos, so that's a plus.

NOTE : Even outside of this whole GUI app VM sandboxing idea, Firecracker could be something great to provide by default for users who want to make secure VMs on Secureblue.

Sommelier

Crostini uses Sommelier to integrate the Wayland apps running in the VM with the host OS seamlessly.

We could use X11Docker (Don't pay attention to the name, you can use it with Wayland and without Docker) to get the same effect.

Other

We could use Kata Containers, which makes VMs that acts like containers. (NOTE: this would also be great to have in general for containers in Secureblue, maybe would it also solve the current issues with containers and user namespace, or are these already solved ?) to make Firecracker and x11docker work together.

So we would have:
Kata Containers using Firecracker to run microVMs that boot very fast, have low memory footprint and are very secure thanks to memory safe language and small attack surface.
Those Kata containers VMs could be used with all the usual "containers" tooling.
x11docker being a container tool and being officially compatible with kata containers could then be used to run GUI apps in our microVMs/containers that would behave and feel like native/normal host OS GUI applications.

All of those are available already in the official Fedora repos, they would just need to be integrated together. Bringing them together, especially if the goal is to provide a completly automated process where users can just install an app from the store and all of that is configured automatically, would be a fairly big project and would probably require a dedicated repo.

I'm aware it's a bit(very) convoluted, but i think it's an idea worth thinking about. It would provide isolation similar to QubesOS (if implemented correctly) with all the usability and performances of a normal OS.

Also many of the ideas here can be used alone to make some other parts of the OS more secure. Kata Containers and Firecracker are very useful by themselve already.

Let me know what you think, i'm interested in what people pursuing similar goals regarding desktop computer security think about the idea.

[RoyalOughtness]

This is a good idea and it could be pulled into secureblue once it's completed. However it would be something that should be developed in a separate project. Secureblue is the place where all the different pieces should come together to form an image. Much like the pam module @34N0 is working on, if you want to work on this and let me know once it's in a testable state, we could incorporate it into secureblue then.

[wandapeter]

I like this idea too. However, it is very complex and feels like major scope creep.

I looked at the components you mentioned in your VM stack. Even though it might be possible, I fail to see how the technologies could be combined into a testable and easily distributable application without having to do major work upstream. Have you had any thoughts about how you would engineer the system?

Another thing about running applications inside a VM would be the GUI app dependencies. How does Crostini fix this problem? Flatpaks are bundled together with a runtime that contains their dependencies. This approach would then mean you would have to provide a build system, an app store, etc. I fail to see how this idea doesn't end up as a next-generation Flatpak with a huge scope requiring community support, funding, etc.

Maybe, as a start, you could try to create a proof-of-concept repository by experimenting with your idea? I would possibly be interested in contributing (especially in Rust), but the scope does need to be much more defined and restricted.

[Malom-ctrl]

Thanks for your feedback guys.
I completly agree that it's most likely way out of the scope of Secureblue to implement such system. I was mainly putting the idea out there to see if it sounded interesting to people with similar desktop security goals. In this regard, i'm glad you also see the value in such system.

It would absolutely need to be it's own separate repo and would need tons of polishing and testing before being considered to be distributed to end users in secureblue (or others).

About how to implement it, how to get all the moving parts to work together nicely, i honestly don't know yet. The idea is just a draft i brainstormed a few weeks ago, nothing more yet.

I indeed think i will first start by making a proof of concept, even if it's of poor quality, just to see if it's something even worth trying to make. It will take some time tho because my RL is pretty busy these days, so don't expect anything soon :)

Now in the meantime, i think some of the components of the stack could be used alone in Secureblue without too much work. For example Kata Containers alone would provide a great isolation for containers in Secureblue (maybe it would solve the current issues with containers Secureblue has ?). Something like Gvisor could also be explored for a similar purpose.
Those, if they can work, would be a great fit given that containers are pretty important and useful on immutable distros. They are also tried and tested projects that are used in production and that are proven to provide a lot of security improvements.

[RoyalOughtness]

@Malom-ctrl I think the first step before you jump into it would be to investigate what solutions already exist that provide comparable functionality. Building a new system that goes unused because another system already exists is both reinventing the wheel and potentially insecure as you'll be using a significantly less battle-tested piece of software. I'll be closing this ticket out since it's out of scope but feel free to keep using it as a discussion spot.

[Malom-ctrl]

I'm aware of the issues security focused apps with small userbase have, such as being hard to evaluate security-wise.
That's why the idea is to base it on existing battle tested projects (talking about Kata and Firecraker here, idk about x11docker) to avoid being responsible for the most critical parts of the system, those which will make or break the security of the system.

The thing is that I'm pretty sure nothing like it exists yet because i've been looking around for similar solutions for a while and i never found anything that really fitted that need.
But if you guys are aware of such project I would be really interested.

In case i start the project or find something interesting on my side i will keep you updated here.

Also, about using Kata or Gvisor in Secureblue "as-is", what do you think ? or should i open another issue to discuss that ?

[RoyalOughtness]

@Malom-ctrl if you're just looking to get gvisor and kata in the images, no need to open an issue 😄

Just open a PR adding golang-gvisor and kata-containers to common-packages.yml

[wandapeter]

@Malom-ctrl Once you start experimenting please post the repo link in this issue. Like i said, i am interested!

[wandapeter]

Because of hardened malloc firefox and firefox derived products like thunderbird are not working on secureblue. So to use thunderbird i did the following:

• I created a new distrobox
• Installed thunderbird
• exported thunderbird with distrobox-export

Now i am able to run thunderbird with access to my hosts /var/home but apart from that it is running in a completely seperate docker container. And it runs quite stable.

Which means achieving qubes like containerized applications is actually quite easy. I can see myself creating a wrapper library for distrobox in rust and create an installer cli tool. What do you think @Malom-ctrl ?

Ofc this doesn't use any fancy new containerization tools like the ones you mentioned but this is at least a working proof of concept.

[RoyalOughtness]

Because of hardened malloc firefox and firefox derived products like thunderbird are not working on secureblue. So to use thunderbird i did the following:

• I created a new distrobox
• Installed thunderbird
• exported thunderbird with distrobox-export

that works, but significantly easier would be just overriding LD_PRELOAD for mozilla products 😄

[wandapeter]

Because of hardened malloc firefox and firefox derived products like thunderbird are not working on secureblue. So to use thunderbird i did the following:

• I created a new distrobox
• Installed thunderbird
• exported thunderbird with distrobox-export

that works, but significantly easier would be just overriding LD_PRELOAD for mozilla products 😄

hmm yep i am stupid but at least it sparked an idea 😄

[Malom-ctrl]

@34N0 Yes distrobox is very handy for installing apps in containers. Though this doesn't answer the same needs as my proposal.

Regular containers (such as docker) are barely considered secure as they share the host kernel with the container. Which means that any app in the container can directly try to attack the host kernel. Also even though Docker now has a rootless mode, many configs still don't use it. Podman is a bit better because it was made with rootless containers in mind. But it still shares the host kernel with the container.

By default they have almost no real security benefits. I guess with some configuration it could be a bit better (restricting permissions) but the core issue (the shared kernel) would still be there.
Regular containers are really more of convenience tools rather than security tools. That's why my initial proposal was using kata containers which are essentially VM pretending to be regular containers in order to fit in the container toolchain.

A very easy way to improve on regular containers significantly without much work needed would be to use GVisor (https://gvisor.dev/) with distrobox (or any other containers management tool).
GVisor presents fake "kernels" with very limited attack surface to the container rather than the host one. It's also written in memory safe language and has been built for security.

So i would say Distrobox with GVisor would be a pretty good way to get a bit closer to the whole idea behind my initial proposal in very short amount of time/work.

I'm busy with work lately so feel free to give that a try and see how it works. If you do please keep me updated of how it goes, especially with the hardened malloc and other secureblue specific things, i'm curious :)

[superuser-miguel]

ChromeOS has a linux apps sandboxing solution called Crostini.
It lets the user launch untrusted code in a completly safe manner being sure it cannot reach the host OS.
It's mainly used to launch GUI apps that then integrate perfectly with the host OS as if they were native apps.

Podman container with selinux context? container_file_t or systemd-nspawn container with sandbox_web_t ??? This has been a linux thing for years.

[Malom-ctrl]

ChromeOS has a linux apps sandboxing solution called Crostini.
It lets the user launch untrusted code in a completly safe manner being sure it cannot reach the host OS.
It's mainly used to launch GUI apps that then integrate perfectly with the host OS as if they were native apps.

Podman container with selinux context? container_file_t or systemd-nspawn container with sandbox_web_t ??? This has been a linux thing for years.

Read the whole issue, it is something completely different.