
How sandboxing works in Fuchsia - btrask
https://fuchsia.googlesource.com/docs/+/master/sandboxing.md
======
negus
"dev, gn, /svc, /pkg, PA_VMAR_ROOT" Hate this old unix approach for name
shortening, what makes them unreadable and non intuitive. If they break
compatibility anyway, they could name things in a way, that people can read
like a book.

~~~
lucb1e
When programming, variables should be self-explanatory. However, things you
re-type constantly (copy -> cp, remove -> rm, variable data -> /var) are fine
to abbreviate with logical abbreviations.

I don't have trouble understanding dev, /svc and /pkg because they're already
common abbreviations. The gn and PA_VMAR_ROOT I'd have to look up, but if I'm
using it constantly, I don't mind needing to learn. I mean, I needed to learn
to use Vim, too, and now I'd never want anything else.

~~~
snarfy
I'd rather have typing assist than abbreviated names. To be self-explanatory,
it's called ISingletonComponentFactory, but that doesn't mean I type all of
that out.

~~~
jstimpfle
Typing assistants mostly suck. And it's not only about the typing. You still
have to read the names or process them otherwise.

"Self-explanatory": That doesn't exist. You always need context. The art is to
use just enough verbosity. Say the interesting and distinctive things. Not the
boring things that can be easily figured out (Singleton, Factory, boring. What
kind of component?)

~~~
josefx
> You still have to read the names or process them otherwise.

And how long does it take you to parse "svc" vs. "service" in average
microseconds per day? With old unix there was at least a need to keep memory
use low, today we are only limited by Microsofts MAX_PATH.

~~~
jstimpfle
What I said was about typing assistants and about efficient naming. But after
reading the article, I would make a point for svc being not a bad decision.
Ask any otherwise uninitiated programmer what meaning she would associate with
"svc" or "service". You don't get anything useful out of either without
additional context. Even

    
    
        /svc, which is a bundle of services from the environment in which the application runs.
    

is not really enough for me to understand what this is about.

Now, since this is a distinctive concept that comes with a learning cost, why
not make a short name like "svc" for it? That is actually more distinctive
than "service". And you save 4 characters every time you read or write it.

------
naasking
Except you can't sandbox or virtualize the clock because mx_time_get() doesn't
require a handle, which makes timing attacks easier.

You also can't sandbox event and channel creation for the same reason. It
looks like these can also DoS the kernel. In general, any operation you can
perform without a handle tends to be subject to DoS and you can't virtualize
it. They're also subject to a different access control policy than the rest of
the system which is based around handles.

And it's not really necessary. Just reserve the first few handles in a process
table for a clock handle, a channel constructor/factory handle and an event
constructor/factory handle, and now these operations can be fully virtualized
and they aren't subject to DoS because they can be rate-limited or at least
traced back to specific handles which can be revoked.

Without tracing every operation to a handle, you have to pollute your model
with more infrastructure to track this information, as with channels and
events in Fuschia.

[1]
[https://fuchsia.googlesource.com/magenta/+/master/docs/conce...](https://fuchsia.googlesource.com/magenta/+/master/docs/concepts.md)

~~~
swetland
The creation syscalls operated under the execution constraints of the Job in
which your Process is contained. The APIs aren't fully landed, but it will
(very soon) be possible to create Jobs where-in none of the kernel object
creation syscalls will be allowed. You can think of the creation syscalls as
taking an implied handle to the Process's Job, which is an "object factory"
similar to what you suggest.

There are mechanisms in the works to allow the VDSO to be customized per-Job
along similar lines (providing a way of addressing mx_time_get(), etc).
mx_time_get() is actually provided entirely in userspace in the default VDSO,
but of course we want to allow for runtime environments where we don't allow
direct access to the TSC or equivalent.

There aren't any "known" handles in the Magenta design, as handles are not
small integers nor aggressively reused (as fds are in unixen). The intention
there is to make use-after-free errors with handles more difficult and to make
guessing what handles a process has harder.

It's definitely not a "pure" capability design or a "pure" (read/write/exit)
microkernel underneath. The goal is to try to be pragmatic and balance
performance and api usability/convenience with the benefits of a capability
system.

It's also a system in development and the shape of things has changed and
almost certainly will change further before we're done.

~~~
naasking
> You can think of the creation syscalls as taking an implied handle to the
> Process's Job, which is an "object factory" similar to what you suggest.

Implicit handles are not explicit handles, and capability security requires
explicit handles. You're obviously familiar with capabilities and the problems
inherent to breaking capability properties, so why violate them in this
instance?

You mention API usability, but mx_get_time() and mx_get_time(clock_sys), where
clock_sys is a static variable initialized by the runtime library at start
isn't really any more unusable. Like printf, you can even wrap it in more
convenient procedures with no parameters, but you can't go the other way and
reify to the clock if that's not how it's designed to begin with.

> There are mechanisms in the works to allow the VDSO to be customized per-Job
> along similar lines (providing a way of addressing mx_time_get(), etc).
> mx_time_get() is actually provided entirely in userspace in the default VDSO

This is exactly what I was talking about though: it's totally unnecessary if
the clock were accessed via a handle. Why build all of this extra
infrastructure when it's completely unnecessary?

Every process would get a set of handles for its basic services, like clock,
scratch folder, what-have-you, and building an isolated process just replaces
the system handles with wrapped ones. What's the deficiency in this approach
that you'd decided to build a more complicated infrastructure instead?

> The intention there is [...] to make guessing what handles a process has
> harder.

I'm not sure what the point of this is. Are handles not partitioned/per-
process like file descriptors? Knowing what file descriptors another process
has doesn't give you access to them or yield any advantages. This is how
object capabilities should work.

~~~
swetland
Yes, handles are partitioned per-process. Having them be unlikely to be reused
or collide with small numbers (locally) helps avoid some common failure cases
(somebody uses a fd after close but somebody else has opened something else
that got the same fd and now you have two problems).

Having them be harder to guess provides some (minor) additional defense
against attempting to remotely exploit bugs in another process.

~~~
naasking
> Yes, handles are partitioned per-process. Having them be unlikely to be
> reused or collide with small numbers (locally) helps avoid some common
> failure cases (somebody uses a fd after close but somebody else has opened
> something else that got the same fd and now you have two problems).

This could be handled in user space without affecting kernel structures using
opaque structs and some runtime bookkeeping.

Alternately, Kernel fds could use the low order 24-bits for the descriptor
itself, with top 8-bits reserved as an allocation count. When a given fd is
closed, increment the counter for the next time it's allocated. You've reduced
the chance of already rare misuse by 256 fold with requiring some kind of
sparse data structure in the kernel.

Perhaps the current handle design is even harder to misuse, but how defensive
should you be for accidental misuse like this?

> Having them be harder to guess provides some (minor) additional defense
> against attempting to remotely exploit bugs in another process.

I've never heard of this kind of exploit. Do you have an example?

------
bitmapbrother
Here are a couple of YouTube video's showing the early stages of the Fuchsia
UI:

[https://www.youtube.com/watch?v=MPhQ-8fXft8](https://www.youtube.com/watch?v=MPhQ-8fXft8)

[https://www.youtube.com/watch?v=Vu0VGj5xf60](https://www.youtube.com/watch?v=Vu0VGj5xf60)

~~~
Apofis
Looks like they are already pretty far ahead. Wonder if they plan to replace
both android and ChromeOS with Fuchsia.

------
legulere
How to request capabilities at run time?

Android has shown that the approach of asking for a list of capabilities while
installing does not work for user-facing applications. Apps will grab just as
much as capabilities as possible and users will blindly accept the long list
without reading.

~~~
geocar
The same way mach does it.

You send a message to a process that dishes out capabilities and it responds
with a handle/port/object that encodes those capabilities.

------
pjjhdog
So I'm not clear what the puropse of fuchsia is. I understand it's an os which
may replace android or chomeos but why the move away from linux based systems?
Both are open source platforms.

~~~
catern
>open source platforms

Part of the motivation is certainly to get away from the GPL requirements of
using Linux, so that Google and its partners can release products to users
that have proprietary modifications to the kernel, without giving those same
users access to the source code of the kernel. That would of course be a
disaster for user autonomy and freedom, but why should Google care about
that...

Edit: This isn't just about the license, but also about the structure of the
code. Fuschia is based on a microkernel. "Microkernel" doesn't just mean
"modular kernel"[1] it also means "run drivers and systems in a separate
process with a separate executable". That imposes performance penalties, but
it can enforce a better programming style... and it also allows low-quality
proprietary vendor code to be isolated from the base system and not have to
pass quality checks or open its source.

[1] Linux is very modular despite being monolithic, and there have been
academic operating systems like [https://en.wikipedia.org/wiki/Language-
based_system](https://en.wikipedia.org/wiki/Language-based_system) which are
extremely modular and well designed despite (or perhaps because of) operating
entirely in ring 0. Microkernels of course _require_ modularity; but
modularity doesn't require microkernel. The key problem with having all your
code linked into one executable, of course, is that it requires you to have
all your code...

~~~
DannyBee
"Part of the motivation is certainly to get away from the GPL requirements of
using Linux,"

Certainly why?

I know, in fact, this is pretty much a non-consideration, so i'm really
curious what makes you believe it is.

In fact, the fuchsia kernel is completely open source, so ...

If you were to bug the SFLC/others, you'd see Google is, in fact, quite happy
releasing kernel changes, and is pretty much one of the only companies that
has either pushed vendors to open source drivers, or, in a number of cases,
rewritten proprietary android drivers as open source just so it can release
them!

However, regardless, even assuming you were right, you end up having to put
together a compliance release either way, and it's not like the kernel part of
that compliance release is any more difficult than the other software.

"That would of course be a disaster for user autonomy and freedom, but why
should Google care about that..."

This will be shocking, but the kernel people working on fuchsia do, in fact,
care about that!

If they didn't, they wouldn't have open sourced everything, including the
kernel.

I'm honestly having a ton of trouble following your logic here.

They want to be able to keep stuff proprietary, but have open sourced it since
day 1. They want vendors to be able to release proprietary drivers, but those
vendors can and already do so for linux?

What exactly do you think is different and horrible?

~~~
catern
Then why is it not licensed under the GPL, like Linux?

~~~
DannyBee
The real answer is because the people involved believe the licenses they are
using are even more free. IE they do not subscribe to the FSF's ideology.

It's their software, so they get to choose. It's like arguing NetBSD should
use the GPL license.

As for why it generally doesn't make sense to use the GPL for this:

Even the FSF doesn't think GPLv2 is the right license for linux?

GPL'ing linux hasn't prevented _any_ of the problems you mention, either in
theory or in practice, so why do the _same thing and hope for a different
result_?

(If you've never read it, i suggest you go read the various threads where
linus, etc explain that in practice, the only approach that works is carrot,
not stick)

It would be the same for Mozilla or anyone else who got popular enough with
GPL software and had lots of vendors and OEMs who used their software.

GPL'ing the kernel or not does not change that some people don't follow the
rules. You can have them sign it in blood if you want. They'll just work
around you or ignore you, as long as there is money to be made. Also, once you
are big enough, cutting them off will just attract regulators.

In practice, you will not get them to follow the rules by having a "war on gpl
violators" any moreso than we have solved the US drug problem by having a "war
on drugs".

If you (or others here) dream is of an ecosystem where everyone is _forced_ ,
under pain of death, to follow the GPL, it's pretty unrealistic. It's not what
happens now, it will never happen.

Rather than pretend that's a realistic way to get people to release source,
i'd rather not pretend. i'd rather see something _different_ tried that may
have some hope of success.

~~~
catern
Sure.

So why not GPL (v3) it anyway, if the GPL is so ineffective?

After all, what you're telling me in your posts is that Google _wants_ vendors
to contribute back, but it can't force them.

I don't want vendors to be able to create proprietary extensions. You claim
Google also doesn't want vendors to create proprietary extensions.

So:

\- If the GPL is effective, why not use it?

\- If the GPL is ineffective, it can't possibly hurt and at the very least it
sends a positive signal. So why not use it?

Edit: I'm not sure why you edited your post rather than reply. But I don't
think you have really answered my question as it is put here. Is the GPL
effective or ineffective? Ineffective, you seem to say. So what's the harm?
You claim you care about sources being released. Am I understanding you wrong?

Maybe some employees of Google don't like the GPL. But simultaneously they
want all driver sources to be released? But simultaneously they think the GPL
is ineffective and won't achieve that?

Your post doesn't really add up. Could you list the reasons why Google isn't
using the GPL for Fuschia as bullet points, or something?

~~~
DannyBee
"\- If the GPL is ineffective, it can't possibly hurt and at the very least it
sends a positive signal. So why not use it?"

1\. Of course it can hurt. that's just silly to say. 2\. As for why not use
it? Because it's ineffective? You answered your own question?

This seems like a pretty basic GPL zealot argument at this point ("It's
completely ineffective but you should do it anyway!") , and i'm pretty
uninterested in continuing such arguments.

~~~
catern
How, exactly, would it hurt? Perhaps by... discouraging use from companies
that want to keep their changes private? I am completely fine with that.
Proprietary code should not be allowed anywhere near the kernel or hardware
support. Would it hurt in any other way?

As a concluding remark, I'll just repost what I posted elsewhere in this
thread:

>Consider what happens if you're wrong. What happens if the GPL actually _is_
the reason why Linux has such wide open-source hardware support? Then say
goodbye to hacking on Fuschia on your own hardware...

>I'm not willing to take that risk.

"I beseech you, in the bowels of Christ, think it possible you may be
mistaken!"

~~~
vertex-four
Linux does not have wide open-source hardware support on mobile phones, so
that argument simply doesn't work in this space - you're arguing in favour of
a supposed status quo that doesn't actually exist in the first place.

------
throw2016
Android for all practical purposes is as good as a closed ecosystem with apps
tied to closed source Google services and the inability to run Linux on your
Android phones. This kind of lip service and self serving tip toeing around
the spirit of open source in many ways does more harm to open source than
closed source.

How is it that devices drivers that work on Android perfectly are not
available for use on Linux? What purpose does this kind of 'open source' then
serve?

Between Arm, its licensees and Google the ball is kicked around with open
source devs struggling for years to make things work. Yet the narrative is
this is no one's fault least of all Google and Arm, the 2 most powerful forces
in the Android ecosystem.

Google the planet's largest spyware and adware company is now making its own
kernel. More power to them but given their track record healthy skepticism of
their objectives and agenda is called for.

~~~
ocdtrekkie
This is definitely true, and I have a lot of issues with Google and their lip
service to open source. (People reading my history will attest, I'm sure.) But
at the very least, Fuchsia will be a lot more secure by design than Android,
and Android is the dominant OS platform on earth. The state we are right now,
where 85% of mobile devices run Android, and 0.7% of them are actually up to
date, is a terrifying place to be from a security standpoint.

~~~
bitmapbrother
Why am I not surprised that you can't even get your percentages correct.

~~~
ocdtrekkie
Sorry, unfortunately I did get my numbers wrong. Based on a chart of Android
versions taken from the Google site, it will probably be at least a month or
two before 0.7% of Androids are running the latest version. My bad!

I keep a running copy of the stats here:
[https://oasis.sandstorm.io/shared/UtPbpOAW2OaV4QpkgwIclqGeGC...](https://oasis.sandstorm.io/shared/UtPbpOAW2OaV4QpkgwIclqGeGC0tC5dYfqg4_c17r3Y)

~~~
simplehuman
Thanks for sharing but I am unable to scroll on Mobile

------
gigatexal
My take is that Fuchsia is Google's attempt to unify their mobile ecosystem
under one proprietary OS like Apple does with iOS (yes, yes I hear you, "But
Darwin is OSS..." try making that into iOS though...): which is a good move
for Google.

~~~
umren
> under one proprietary OS

fuchsia and all it's components are licensed under BSD 3 clause, MIT, Apache
2.0

~~~
jhasse
Which means they can fork it anytime into a proprietary one.

~~~
alexvoda
They can do that regardless of the license since they own the copyright. As
long as they do not accept external contributions or require a CLA it does not
matter what license they offer, they can still make future versions
proprietary.

~~~
Matumio
Even if they accept contributions normally (e.g. under the same license), the
above licences will allow them (or anyone else) to make a proprietary fork.

------
DonbunEf7
If you're going to have capability-based security, please be louder and
prouder about it.

~~~
nickpsecurity
Maybe. They start with names. However, the description looks more like access
control lists than what I saw in KeyKOS, LOCK, EROS, E, or Combex's work.

~~~
stefankomatsu
> An empty process has nothing > Namespaces are the gateway to the world

Sounds like capability security to me. Although I wish they had said more
about how these namespaces work. If they are inheritable and you can
virtualize them for child processes (as you can in Plan 9/Inferno) then I'd
say it qualifies.

~~~
abarth
When you create a child process, you can clone your namespace or you can
construct a new one for the child.

(Disclosure: I wrote the doc linked above.)

~~~
stefankomatsu
Thanks. How about virtualization? Using an example from the doc, if your child
process accesses "/dev/class/framebuffer", can you intercept its
communications? Can a process create a custom sandbox and run, say, AppMgr
with limited permission to limit the permissions of all apps it manages?

~~~
abarth
> Using an example from the doc, if your child process accesses
> "/dev/class/framebuffer", can you intercept its communications?

Yes. When creating the namespace for the child, the parent can map names to
what whatever communication channels it chooses. If the parent wants to
interpose on the child's access to "/dev/class/framebuffer", the parent could
map that name to a channel that leads back to the parent.

> Can a process create a custom sandbox and run, say, AppMgr with limited
> permission to limit the permissions of all apps it manages?

Yes. That's useful for testing as well as for sandboxing.

~~~
btrask
Thank you for taking the time to reply, despite the sea of low quality
comments on this HN thread.

------
mtgx
Too bad Fuchsia isn't also written in Rust.

------
czeidler
Sound like Genode: [http://genode.org/documentation/general-
overview/index](http://genode.org/documentation/general-overview/index)

------
omarforgotpwd
Sounds kind of like the rebirth of plan9

~~~
digitalzombie
Well they got the same artist that made glen the rabbit to make the gopher for
Go.

Maybe they can get that artist to do a mascot for Fuchsia.

~~~
stock_toaster
Renée French is the artist. She is married to Rob Pike.

