Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How sandboxing works in Fuchsia

fuchsia.googlesource.com

Post reply on HN
Print view View original

21–30 of 172 posts

Re: How sandboxing works in Fuchsia

#21

Post by stefankomatsu »

nickpsecurity wrote: post #4
DonbunEf7 wrote: post #3

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

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.

> 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.

Re: How sandboxing works in Fuchsia

#22

Post by tyingq »

dikaiosune wrote: post #18
tyingq wrote: post #15

Earlier quoted context omitted.

Perhaps. The current set of boot instructions are for a NUC desktop, a laptop, and 2 ARM dev boards though. https://fuchsia.googlesource.com/magenta/+/master/docs/targe...

The hardware in that Acer laptop looks surprisingly similar to what a current flagship phone has in terms of resources if not exact architecture.

I guess generically in that it has a touchscreen, limited hdd size, etc. It's an i5 Intel x64 CPU though.

Re: How sandboxing works in Fuchsia

#23

Post by abarth »

stefankomatsu wrote: post #21
nickpsecurity wrote: post #4

Earlier quoted context omitted.

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.

> 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.

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.)

Re: How sandboxing works in Fuchsia

#24

Post by DannyBee »

catern wrote: post #8
pjjhdog wrote: post #2

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.

>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…

"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?

Re: How sandboxing works in Fuchsia

#25

Post by DannyBee »

catern wrote: post #17
djsumdog wrote: post #16

Earlier quoted context omitted.

Companies are embracing open source these days, but not the GPL. We see that with gcc and clang, or in the way MacOS uses older versions of tools just to avoid GPLv3: http://penguindreams.org/blog/the-philosophy-of-open-source-... The OSS utopia pushed in the the 1990s, with tools like Gimp being one day comparable to Photoshop, never really happened.

OK, but that's irrelevant. Kernels are an entirely different class of thing. I'm fine with permissive licenses for higher-level software such as clang or GIMP. But I'm not looking forward to a world where I can't get the source code for a kernel that will actually run on real hardware. It's already painful to compile and run Android from source. Fuschia will make it just impossible.

"But I'm not looking forward to a world where I can't get the source code for a kernel that will actually run on real hardware. "

You literally live in this world right now.

"It's already painful to compile and run Android from source. Fuschia will make it just impossible."

You can literally go download and compile the entire fuchsia kernel, right now.

How is that "impossible"?

Re: How sandboxing works in Fuchsia

#26

Post by nickpsecurity »

abarth wrote: post #23
stefankomatsu wrote: post #21

Earlier quoted context omitted.

> 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.

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.)

Someone told me there were ex-devs of QNX microkernel doing Google's. Is that true?

Re: How sandboxing works in Fuchsia

#27

Post by nickpsecurity »

DannyBee wrote: post #25
catern wrote: post #17

Earlier quoted context omitted.

OK, but that's irrelevant. Kernels are an entirely different class of thing. I'm fine with permissive licenses for higher-level software such as clang or GIMP. But I'm not looking forward to a world where I can't get the source code for a kernel that will actually run on real hardware. It's already painful to compile and run Android from source. Fuschia will make it just impossible.

"But I'm not looking forward to a world where I can't get the source code for a kernel that will actually run on real hardware. " You literally live in this world right now. "It's already painful to compile and run Android from source. Fuschia will make it just impossible." You can literally go download and compile the entire fuchsia kernel, right now . How is that "impossible"?

"You can literally go and compile the entire kernel, right now."

Android discussions started that way. Things changed after enough time and revenue with a huge gap between ASOP and Android experience. Their security fixes vs Apple are also now abysmal. Might be a hint at the future of Google's next OS.

Re: How sandboxing works in Fuchsia

#28

Post by stefankomatsu »

abarth wrote: post #23
stefankomatsu wrote: post #21

Earlier quoted context omitted.

> 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.

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.)

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?

Re: How sandboxing works in Fuchsia

#29

Post by cjhanks »

theDoug wrote: post #10
mee_too wrote: post #9

Earlier quoted context omitted.

They can't be louder and prouder about it, because they know at one point they'll have to compromise it so that Google own apps can track the user.

Oh damn, you broke the triple secret NDA. Next people will find out that Fuchsia is the color faces need to get before the project is revealed to be a conspiracy theory generator. There are plenty of important reasons for this project, that plenty of people in the past have already made note of. If the one you're going for, already, is some ad/user tracking platform, you're purposely attempting to narrow the capabili…

Conspiratorial or not - on Google platforms, 3rd party applications are 2nd class citizens. Do you think an outside party could write Open-WIFI given the present service integration policies?

Re: How sandboxing works in Fuchsia

#30

Post by catern »

DannyBee wrote: post #24
catern wrote: post #8

Earlier quoted context omitted.

>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…

"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 co…

Then why is it not licensed under the GPL, like Linux?
Post reply on HN