Fuschia - a capability based OS designed for security

I wonder if Fuschia OS would be a basis for Safe Network OS or a useful influence.

I don’t know much about it so creating a topic to put it on our radar.


So what does a “degoogled” version of Fuchsia look like? From this it seems the two upper layers of the OS “Topaz” and “peridot” may need to be replaces as it looks like they’re quite dependent on Google services, maybe parts could be reused though.

Seems pretty interesting though.

The sandbox model is originally used to run untrusted code, unreliable software, or to open questionable documents. The basic idea is that no program (process) can access data outside its sandbox. One approach is to create an operating system based on security through isolation with virtual machines (which is far from lightweight). Another approach is a capability-based operating system using a microkernel called Zircon, which is still under heavy development.

For the first approach there is Qubes OS.


If they developed a way to truly run applications sandboxed from the rest of the OS without VMs/containers that is quite an impressive feat. The close associations with Google do concern me, though. I’ll continue using Qubes for the time being until I see how this develops.



What do you mean by truly sandboxed without VMs/containers? If I take what you’re saying to mean genuinely unable to access other files and processes on the system, I think Guix has that solved. This is a long article, so here’s the relevant quote near the start to whet anyone’s appetite who may be interested:

"A major element of reproducibility support in Guix is the possibility to run programs in well-defined environments that contain exactly the software packages you request, and no more. So if your program runs in an environment that contains only a C compiler, you can be sure it has no other dependencies. Let’s create such an environment:

guix environment --container --ad-hoc gcc-toolchain

The option --container ensures the best possible isolation from the standard environment that your system installation and user account provide for day-to-day work. This environment contains nothing but a C compiler and a shell (which you need to type in commands), and has access to no other files than those in the current directory.

If the term “container” makes you think of Docker, note that this is something different."

The italics is from me there. I am only at the start of my playing around in Guix and haven’t played with this specifically yet, so if I’m missing something or misunderstanding I’m happy to hear about it.

Otherwise, Fuschia looks interesting, especially the microkernel and the modular architecture. Google services and such would be a red flag for me also, I must say, but I’m curious to see where it goes.


What caught my eye with Fuschia was the combination of capability based access control and focus on security, including same boxing. I was just searching to find out how Guix compared in these respects but it appears to be a different animal: a package manager rather than an OS. Still may be relevant to Safe Network, but I’m not sure it’s relevant to this topic.

That sounds closer to a chroot’d environment. I’d have to look closer into it, but I would be wary of its ability to be truly “containerized” from the entire OS.

In short, Fuchsia’s unique security properties “do not – and in fact, cannot – hold in the lowest layers of the kernel related to virtualisation, exception handling and scheduling, and that any bug here remains exploitable just like on any other OS.” Despite this, they concluded, it has the potential to “significantly increase the difficulty for attackers to compromise devices.”


I read a bit about capability based access control there, it looks interesting alright - how do you imagine it complimenting Safe? It sounds good but I am not getting a clear picture.

Guix is a package manager and also most definitely an OS, I’m writing here from a browser in Guix. It does some fun stuff, the other day after some messing around with the system a little too much, audio stopped working. With one command I rolled back to an exact copy of a previous state, where I knew it had been working before, and all was well.

I also think it is relevant to the topic in terms of the security, if brainstorming possible useful influences is the goal here. They are aiming for fully reproducible fully free operating systems, and because of the functional nature of the system it has some relevant properties I feel.

This article is the best and clearest I could find, it’s short: Why GNU Guix matters I’ll stop insisting after this post anyway, and go back to reading :smiley: I really do think it’s relevant and am not trying to derail the thread.


This is excellent, on sandboxing, containers, vms, chroot, namespaces:

There been a fair amount of discussion and advocacy for capability based access and MaidSafe decided to implement it for Safe Network some time ago. @joshuef did some work on this a couple of years ago, but I’m not sure if it has survived the changes since then. Hopefully so as I think much of the way SN App mock-ups worked was based on this assumption.


Oh lovely, I missed that, or it went over my head at the time. Off for a read, cheers


It’s backburnered at the moment. The crux of the idea (of what was ‘tokens’… would need a rename now) was some validation of a macaroon like object at the data holding nodes.

Should still be possible to do I think.


I think the answer will be found in Rust and Web Assembly space. I can’t find the link atm but remember reading about teams working on a very minimal Rust based OS that supports Web Assembly and not much else. Sounds perfect.

Capability-based here means that the APIs don’t access files, directories, network addresses, clocks, or other external resources implicitly, but instead operate on handles that are explicitly passed in. This helps programs that work with potentially malicious content avoid accidentally accessing resources other than they intend, and does so without the need of a traditional process-wide sandbox, so it can be easily embedded in larger applications.

Introducing cap-std, a capability-based version of the Rust standard library



I clocked Fuchsia some time ago and had it pegged for this sort of thing; although I hadn’t checked in on it’s progress for a while.

As Josh says, we are most definitely designing with this kind of end in mind—hence the capability based control over data access running though the UX designs—but are just dialling right in to get the core of the Network in place first.

But it’s always in the forefront of my mind, as I’m sure the devs will tell you. :laughing:


You’re maybe thinking of:

Looks interesting, for sure.

EDIT: actually, I suppose you could have been talking about any of these 11 Rust based oses :smiley:


Redox is a more full featured traditional OS. The one I am thinking of was hyper focused on running webassembly/WASI. A quick search it might have been Kwast but not sure I seem to remember a bigger team behind the effort…


I’m liking the Tock project. Having SN on embedded devices seems nice - specific apps tied to specific hardware for specific tasks. Also RISC-V support in the future is also nice.


ahh, nice. i found the nebulet project very interesting, but it got discontinued. I think the main reason for that was spectre/process separation issues.

Don’t think that’s the right class of hardware/software the SN is going to run on. SN needs at least some higher software features, like networking, filesystem, memory (heap) and more than a micro controller as a cpu for crypto etc.

But a custom filesystem would be very cool. The SN is going to issue mostly append only writes to the disk (for immutable data). This is what shingled HDDs are best for, they offer the best space efficiency for append only data. But do not support “normal” filesystem because of the way they store the data. SSD are in fact very similar to shingled hdds, but add a layer on top of that to hide its nature.

1 Like

Should do fine. And there are a huge number of applications IMO, also more security as each device is going to be very limited.

1 Like

Ohh… You meant the client? Not the SN running on embedded? Makes sens. I assumed somehow that you meant the node. Devices with integrated networking should hopefully have enough cpu perf to do the crypto in a reasonable amount of time.