A Kernel Hacker Meets Fuchsia OS • Hacker News Board

Re: A Kernel Hacker Meets Fuchsia OS

#91

Post by fartcannon » Wed, May 25, 2022, 2:11 PM UTC

Ruq wrote: post #88

It sounds like a really bad idea to have all software "components" be resolved, downloaded, and executed from over the internet. Seems like a supply chain/waterhole attack just waiting to happen. Not to mention it would seem to sign away the devices ability to act autonomously or offline. Of course, with my views of Google, it seems very like them to design everything to constantly rely on them to even function. Corr…

They're claiming its about trusting the code you run. Google, you're the source of the code I don't trust.

Re: A Kernel Hacker Meets Fuchsia OS

#92

Post by pjmlp » Wed, May 25, 2022, 2:13 PM UTC

ouid wrote: post #65

The objective of computer security seems to have shifted from preventing someone else from running unauthoirzed software on your computer to preventing you from running unauthorized software on your computer. I would not describe this as security.

It was always been like that in properly configured enterprise systems, that is why we used to connect to UNIX development servers, instead of having a worstation on each desk.

And later moved into having workstation VMs accessed on the network as soon as PC virtualization catched with what mainframes have been doing for decades.

Re: A Kernel Hacker Meets Fuchsia OS

#93

Post by londons_explore » Wed, May 25, 2022, 2:15 PM UTC

Ruq wrote: post #88

It sounds like a really bad idea to have all software "components" be resolved, downloaded, and executed from over the internet. Seems like a supply chain/waterhole attack just waiting to happen. Not to mention it would seem to sign away the devices ability to act autonomously or offline. Of course, with my views of Google, it seems very like them to design everything to constantly rely on them to even function. Corr…

I like the idea of it being possible. Just because it's a feature doesn't mean you have to use it.

For one thing, I assume such a system would have the ability to pin certain versions/hashes. If I (the user) can pin a set of hashes that are allowed to run, then I don't care where the actual resources are downloaded from.

Alternatively, if I can give a certificate I trust of someone else to give a 'realtime' list, that would also satisfy my needs.

Re: A Kernel Hacker Meets Fuchsia OS

#94

Post by londons_explore » Wed, May 25, 2022, 2:17 PM UTC

DannyBee wrote: post #54

nine_k wrote: post #27

My takeaway from the article is that Fuchsia exposes a capability-based interface externally, but uses the old kind of privilege-checking inside the kernel. Once a single sloppy check was found, the game was over: a privilege escalation and planting of arbitrary code into the kernel followed. Did I miss anything?

Yes - you can't run untrusted native code in the first place outside of the emulator ;) That's why the bug says: "The overall impact of this bug is pretty minimal in our current set of supported products, since none support running untrusted native code, and if you can run your own code on the system, then (at present) you can also use other existing supported workflows to obtain kernel logs, but it does seem to be a…

Don't forget that the use-after-free used was also artificial - ie. OP didn't discover one, he added a UAF bug to go exploit.

The fact he got KASAN working and talks about fuzzing suggests he looked for one, but couldn't find one, which is a good sign.

Re: A Kernel Hacker Meets Fuchsia OS

#95

Post by pjmlp » Wed, May 25, 2022, 2:17 PM UTC

dec0dedab0de wrote: post #31

native_samples wrote: post #19

I think the more interesting thing here is the fact that so much code in their repository appears to be bit-rotted or half baked, despite being documented. KASLR is mentioned all over the place but doesn't work and the answer is "we know, it's there only to stop it bit-rotting". You need to patch the system to do kernel debugging because otherwise the toolchain hangs. Syscalls are documented as enforcing security rul…

It's hard not to feel like maybe Google has lost the ability to develop operating systems. Did they ever have that ability? I know they did a bunch of work for Android/Chrome OS. But both of those are Linux, have they tried to develop an OS from scratch before fuschia?

Android and Chrome OS use the Linux kernel, that is all.

Everything else, including driver subsystem (Android docs even calls classic Linux drivers legacy), doesn't have anything to do with GNU/Linux.

Re: A Kernel Hacker Meets Fuchsia OS

#96

Post by ryandvm » Wed, May 25, 2022, 2:22 PM UTC

kramerger wrote: post #25

bitwize wrote: post #23

The great thing about Fuchsia is it's like a Google version of Plan 9. The bad thing about Fuchsia is it's like a Google version of Plan 9.

The bad thing about Fuchsiais that it's a Google product. They may decide to kill it next week and switch to XNU or symbian or templeos and no one would be surprised.

Google's proclivity for aggressively wiping the spaghetti off the wall is starting to work against it. I think maybe they need to start promising to open source any products they lose interest in.

Re: A Kernel Hacker Meets Fuchsia OS

#97

Post by wittrock » Wed, May 25, 2022, 2:23 PM UTC

londons_explore wrote: post #93

Ruq wrote: post #88

It sounds like a really bad idea to have all software "components" be resolved, downloaded, and executed from over the internet. Seems like a supply chain/waterhole attack just waiting to happen. Not to mention it would seem to sign away the devices ability to act autonomously or offline. Of course, with my views of Google, it seems very like them to design everything to constantly rely on them to even function. Corr…

I like the idea of it being possible . Just because it's a feature doesn't mean you have to use it. For one thing, I assume such a system would have the ability to pin certain versions/hashes. If I (the user) can pin a set of hashes that are allowed to run, then I don't care where the actual resources are downloaded from. Alternatively, if I can give a certificate I trust of someone else to give a 'realtime' list, th…

Hi there, I work on Fuchsia, specifically on our Software Delivery system [1].

You hit on exactly the right point: it's _possible_ to download and run software on demand, but it's also possible (and recommended) for products to turn off that capability if it's not useful or valuable for their use case. We pin packages for the base system itself, as well as lots of configurations of products.

The ability to run code on demand is really valuable for our development flows and quick prototyping: built a new test or experiment? No need to update your device, just try to run it, and it runs!

[1]: https://fuchsia.dev/fuchsia-src/get-started/learn/intro/pack...

Re: A Kernel Hacker Meets Fuchsia OS

#98

Post by tech-historian » Wed, May 25, 2022, 2:25 PM UTC

dvh wrote: post #77

You see, this is how you do job interview, not waiting for some HR schmuck to ask you leetcode questions over the span of 6 months.

Marketing yourself has always been, and will continue to be, valuable. This marketing can take many forms.

Re: A Kernel Hacker Meets Fuchsia OS

#99

Post by goodpoint » Wed, May 25, 2022, 2:25 PM UTC

dmitrygr wrote: post #24

The people who work on fuchsia are very good engineers - I’ve worked with many of them in person. But the project itself has always been a staff retention project. It only existed to keep said engineers from going to a competitor. I don’t know how any understanding of fuchsia is possible without this crucial fact

Unlike Linux, Fuchsia is not under GPL. Another attempt at making Android less open.

Re: A Kernel Hacker Meets Fuchsia OS

#100

Post by bregma » Wed, May 25, 2022, 2:26 PM UTC

ouid wrote: post #65

The objective of computer security seems to have shifted from preventing someone else from running unauthoirzed software on your computer to preventing you from running unauthorized software on your computer. I would not describe this as security.

We will do what we're told.