Live data from Hacker News

A Kernel Hacker Meets Fuchsia OS

a13xp0p0v.github.io

111–120 of 296 posts

Re: A Kernel Hacker Meets Fuchsia OS

#111

Earlier quoted context omitted.

I think you are downvoted because you touch on the BLM/Asian Pacific stuff, which tickles people. But yeah you are also very right.

Just because they have those banners up doesn't mean those point to some latent reason for whatever is responsible for their woes. Granted it gives a window in to the culture of the Fuschia team at Google, but to me, personally, it doesn't come off as virtue-signalling at all but rather a conscious effort to put diversity and inclusion in the front and center of what they do. As another example, Google has had socio-…

To me it comes off as inclusive of Americans while excluding the rest of the world. As a European I do not feel welcome, and I imagine people further from US culture feel even less welcome.

Re: A Kernel Hacker Meets Fuchsia OS

#112
post #90
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 would tend to agree, unless pinning is enforced/the default.

I think the idea is "ensuring software is always up to date", so no pinning by default.

Re: A Kernel Hacker Meets Fuchsia OS

#114

Earlier quoted context omitted.

Interesting. Is this in practice implemented as just capabilities being large numbers so it's impractical to guess them, or does the kernel have a table with all of a process's capabilities and when a message is sent to a process with capabilities the kernel adds them to the table? That is -- are capabilities just pieces of data in a message you can detect and try to use, or do they have to be added explicitly to a m…

You know a limited kind of capability - file descriptors (or kernel handles). Those are just a number that allow you to manipulate some object in a defined way. You can give this number to someone else, and they can't make use of it at all, you have to go ask the kernel (using e.g. a unix socket and ancillary messages) to pass the capability to another process.

That is sort of the opposite of a capability. In fact, files are capabilities exactly because you can hand off a file descriptor and, by virtue of that handle, you grant access.

File systems aren't actually capability based (generally, in practice) because you can 'ls' and 'cd ../'. Otherwise they could be.

Dropbox Paper is a good example of a capability based system. Anyone with a URL can perform actions on a page, but there is no way to derive a URL without already having access to it, you must be told what it is. This is because the urls are sufficiently random so as to be unguessable.

Re: A Kernel Hacker Meets Fuchsia OS

#115

Fuchsia still makes me deeply nervous inside. I get that linux has plenty of problems, but it really feels like Google have started to write an OS for the purposes of (a) having better remote control over the software that users run, and (b) being able to be free of the GPL. Security is the panacea that lets this happen, but I'm really not sure that it will inherently be better: iOS has effectively this model and it…

People say this about a lot of security things. Ultimately, a lot of security is about constraining systems, and that makes people nervous. When I got my first Android phone I could root it pretty trivially and run a fully customized ROM, these days it's not really practical on many devices. And for the same exact reason that I have less control over my phone, I also trust it radically more for my current threat mode…

> People say this about a lot of security things

Unfortunately those people are often correct.

Re: A Kernel Hacker Meets Fuchsia OS

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

The intent of the post isn’t to claim that any Fuschia device currently sold is vulnerable. Unless Fuschia never graduates to running third-party code, that seemed like the right assessment to me.

Re: A Kernel Hacker Meets Fuchsia OS

#117
post #2

Very nice right up on how unfinished and insecure Fuchsia is as a result of it being so unfinished.

>Very nice right up on how unfinished and insecure Fuchsia is as a result of it being so unfinished.

Did you even read the write up? The only bug found was the ability to read the kernel log. Everything else was manufactured.

Re: A Kernel Hacker Meets Fuchsia OS

#118
post #73
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.

I would guess you have never worked as a technical suppport for your family’s computers? Because even if I very much understand your point, not being able to run untrusted code absolutely is a security advancement in certain situations. It is SO refreshing and liberating to be able to say: Do whatever you want with it, it’s very hard to damage on the software side.

This is not what ouid wrote.

Re: A Kernel Hacker Meets Fuchsia OS

#119
post #90

Earlier quoted context omitted.

I would tend to agree, unless pinning is enforced/the default.

I think the idea is "ensuring software is always up to date", so no pinning by default.

These things work in tandem: the base system is pinned, but can also be easily updated with an OTA. Packages existing outside that set are resolved on-demand, and are thus updated when components in a package are run after a new version is published to the package repository.

Re: A Kernel Hacker Meets Fuchsia OS

#120
post #20

Earlier quoted context omitted.

That would be too hard, it's a kernel that's actually developed with security in mind and is subject to active research (e.g. by DARPA).

If you try using sel4 in a project, you soon realise it is extremely limited and not at all useful for general purpose computers

And yet it works on Genode/Sculpt! :)

(yes... it's also a very limited OS... maybe someday it gets a decent GUI and starts to get more attention)

Post reply on HN