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

A Kernel Hacker Meets Fuchsia OS

a13xp0p0v.github.io

Post reply on HN
Print view View original

181–190 of 296 posts

Re: A Kernel Hacker Meets Fuchsia OS

#181

Post by DashAnimal »

turminal wrote: post #115
staticassertion wrote: post #110

Earlier quoted context omitted.

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.

Please I beg you - don't let HN become another online discussion site. Aim for quality, give examples, don't just rely on vague comments that are meant to provoke emotion and nothing else.

Re: A Kernel Hacker Meets Fuchsia OS

#182

Post by staticassertion »

Rusky wrote: post #155
throwaway894345 wrote: post #144

Earlier quoted context omitted.

Are capabilities rotated periodically? Or how do you deal with leaked values?

It doesn't matter if the value is leaked, because it's meaningless to another process- like a file descriptor, it's just an entry in a table in the kernel, so it can only be used by the process it was granted to. (One process can request that the kernel transfer it to another process, which I guess you might be referring to? I'm not familiar with Fuchsia specifically here but generally speaking capability-based desig…

> It doesn't matter if the value is leaked, because it's meaningless to another process- like a file descriptor, it's just an entry in a table in the kernel, so it can only be used by the process it was granted to.

No, this is incorrect. Let's just quote wikipedia,

> A capability (known in some systems as a key) is a communicable, unforgeable token of authority.

communicable. It is practically the whole point that you can say "hey, here's a capability I have, now you have it".

Yes, it matters deeply if a capability is leaked. To name something is to authorize something, in capabality land.

No, you do not need to ask for it to be transferred. As with file descriptors in linux you can fork to delegate (or otherwise pass the handle around). Again, it is fundamental to capabilities that the capability is the authorization.

Dropbox's approach is faithful. And, in order to deal with these limitations of capability systems, Paper supports ACLs as well as capabilities. I think it's going to be a huge problem if Fuschia doesn't, but I don't know what they do - certainly some sort of MAC is desirable.

Re: A Kernel Hacker Meets Fuchsia OS

#183

Post by staticassertion »

throwaway894345 wrote: post #162
Rusky wrote: post #155

Earlier quoted context omitted.

It doesn't matter if the value is leaked, because it's meaningless to another process- like a file descriptor, it's just an entry in a table in the kernel, so it can only be used by the process it was granted to. (One process can request that the kernel transfer it to another process, which I guess you might be referring to? I'm not familiar with Fuchsia specifically here but generally speaking capability-based desig…

No, I just didn’t realize that it wasn’t useful to another process. I thought it was akin to a secret.

To be clear, the answer to your question is "yes, you need a way to revoke capabilities if you care about them leaking", and the user who responded to you is incorrect.

Re: A Kernel Hacker Meets Fuchsia OS

#184

Post by staticassertion »

trasz wrote: post #138
staticassertion wrote: post #114

Earlier quoted context omitted.

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

>File systems aren't actually capability based (generally, in practice) because you can 'ls' and 'cd ../'. Otherwise they could be. That's precisely how it works in FreeBSD ( https://www.freebsd.org/cgi/man.cgi?capsicum ).

"generally, in practice"

There's also openat on linux. My point is that the general, practiced approach is not capability based.

Re: A Kernel Hacker Meets Fuchsia OS

#185

Post by ncmncm »

PaulDavisThe1st wrote: post #85
ncmncm wrote: post #51

Earlier quoted context omitted.

Downvote all you like, it is bad code all the same.

If you said why, you'd be less likely to get downvoted. Hand-waving assertions of "that dreck" are not well judged.

Anybody who can look at the reproduced code and not recoil in disgust will be unlikely to understand a detailed criticism. Just read it!

Re: A Kernel Hacker Meets Fuchsia OS

#186

Post by fartcannon »

corrral wrote: post #179
fartcannon wrote: post #176

Earlier quoted context omitted.

You can have a locked down mode. You can even sell it turned on by default. But to exclusively prevent everyone from using their computers as they see fit because you think some people are too stupid to handle it? I don't believe you actually want that. I believe that's an excuse to ensure Apple gets a cut of everything that happens on their soon to be landfill machines. If yes, man that's really dangerous thinking.

I have almost zero interest in haxoring my phone, and just want it to always work and not let 3rd parties steal my info, automatically. And I'm a life-long computer geek who's done professional mobile development. Most people care even less than I do. They just want it to work, because computers aren't their life, they just use them to get stuff done, or when someone else tells them they have to. Would it be sort of…

For one, being able to use your computer/phone like a computer isn't 'haxoring'. Jesus. And second, Apple _lets you_ now (mostly anyways), because people with sense still raise a stink. So, basically, you're welcome. Stop screwing it up for the rest of us.

Re: A Kernel Hacker Meets Fuchsia OS

#187

Post by cptskippy »

guyzero wrote: post #161
cptskippy wrote: post #139

Earlier quoted context omitted.

This sounds like exactly the kind of enterprise OS running on Servers that Google wants for itself. Not something for consumer devices.

You'll be surprised of the first commercial deployment of Fuchsia then: https://www.theverge.com/2021/8/18/22630245/google-fuchsia-o...

I guess that makes sense. Those screens are black boxes as far as the user is concerned and highly dependent on the cloud to even function.

I guess I was thinking more Laptops and Phones.

Re: A Kernel Hacker Meets Fuchsia OS

#188

Post by staticassertion »

throwaway894345 wrote: post #144
staticassertion wrote: post #114

Earlier quoted context omitted.

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

Are capabilities rotated periodically? Or how do you deal with leaked values?

A leaked capability is indeed a critical failure. There are multiple ways to deal with that.

1. Revocation is pretty critical

2. Bounding of capabilities is great - "You have this right for N seconds", meaning that a leak is less devastating

3. Not relying on capabilities is the best option. Capabilities are amazing, and a wonderful access control system. Their main benefit is that you can very naturally implement extremely fine grained access control. The downside is that it becomes hard to reason about that access control statically. ACLs are bad at super fine grained access control, but they're great for "I can look at a policy and know what this thing can/ can not do".

Layering ACLs and capabilities is a match made in heaven.

Re: A Kernel Hacker Meets Fuchsia OS

#189

Post by phlip9 »

londons_explore wrote: post #94
DannyBee wrote: post #54

Earlier quoted context omitted.

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.

From the article, it looks like the syzkaller fuzzer integration was stale and not working, so there might still be some juice to squeeze if someone can get that running again : )

Re: A Kernel Hacker Meets Fuchsia OS

#190

Post by [deleted] »

bobthecowboy wrote: post #180
vander_elst wrote: post #172

Earlier quoted context omitted.

But given that's open source shouldn't it be a bit better? If I don't agree with some parts of the OS I can fork the project and remove some stuff. Given that's open source you don't have to fully trust Google, you can check things yourself. I know I'm probably bring native, but I am hoping to see some changes in the space.

MIT means it's only open source for as long as Google feels like it should be (and only the parts they want to keep open). Older versions will still be around to fork from, but maintaining a fork of an OS is a pretty large task. Android is also open source, and is notably very difficult to simply fork and do your own thing and then actually use the thing , unless you happen to be a handset maker. My OS entirely drive…

[deleted]
Post reply on HN