4 ms·
I don't really know how does it work in Fuchsia but AFAIK it is supposed to implement capability-based access control giving the apps access only to what and wh
by qwerty456127 5y ago
I don't really know how does it work in Fuchsia but AFAIK it is supposed to implement capability-based access control giving the apps access only to what and when they really are meant to access (rather than everything the user who launched them is eligible to access). I believe constraining native apps written for traditional OSes this way may not be trivial.
- nousermane 5y agoIIRC, Linux-based Android did that from day 1. Every app runs as different "user" from the kernel perspective. Plus, you have various [LSM]s as a safety net. Android was an early adopter of SELinux, and latest releases still use it. [LSM] https://en.wikipedia.org/wiki/Linux_Security_Modules https://en.wikipedia.org/wiki/Linux_Security_Modules
- adib 5y agoExcept that Android apps tend to ask for just about all entitlements available. Translation: effectively back to square 1.
- deleted 5y ago[deleted]
- qwerty456127 5y agoYes, this is a huge problem. I wish Google would enforce zero-tolerance policy against apps misusing this mechanism and asking for permissions they don't really need for fulfilling their actual function.
- deleted 5y ago[deleted]
- roblabla 5y agoFuchsia's capabilities mechanism are strictly superior. There has been, over various android version, many fixes to "leaks" of information due to the SELinux configuration not being comprehensive enough, and linux being default open when it comes to capabilities. In contrast, Fuchsia is default closed, so if you don't ask for the permission to do something, you can't. I distinctly remember ad companies using various tricks like reading /proc and the like to try and get information about what applications are running on a phone and what servers they are communicating with without asking for perms (it's fixed now, but it used to be a thing years ago). This is the kind of stuff that fuchsia should, in theory, prevent.
- deleted 5y ago[deleted]
- snvzz 5y agoCapabilities are not what you think they are. Refer to Genode Handbook for a decent definition and examples. seL4 is formally proven to enforce capabilities.
- qwerty456127 5y agoWhat OSes other than Fuchsia are built on seL4? I'd like to try such an OS on a PC, or a Raspberry Pi or in a VM.
- snvzz 5y agoFuchsia is not built on seL4. Genode is, and should be reasonably easy to test on a regular PC, via bootable usb stick. It can be quite confusing to use at first, as capabilities have GUI representation. There's a blog[0] and some introductory video[1]. [0]: https://genodians.org/ https://genodians.org/ [1]: https://youtu.be/vmgWgzeKAjU https://youtu.be/vmgWgzeKAjU
- trasz 5y agoCapability-based security has been available in FreeBSD for a decade now: https://en.m.wikipedia.org/wiki/Capsicum_(Unix) https://en.m.wikipedia.org/wiki/Capsicum_(Unix) The real problem at the moment is not the OS, it’s the applications written or modified to use it.
- qwerty456127 5y ago> When a process enters capsicum mode, Can it be forced to? > it loses all permissions normally associated with its controlling user, with the exception of "capabilities" it already has in the form of file descriptors. What if we want to grant an app already running a new capability on the fly? E.g. I imagine a case of user opening a file in a GUI app as an OS-level file selection dialog getting invoked (provided the app already has a capability to invoke it, as by the manifest) and producing a capability for the app to access the file the user choosse in an explicitly specified (RO or R/W) mode.