3 ms·

> Exploits in the Linux kernel are very few & far between. That's an interesting take on multiple code execution bugs per year. And not via drivers, but userla

by wahern 5y ago

> Exploits in the Linux kernel are very few & far between. That's an interesting take on multiple code execution bugs per year. And not via drivers, but userland-exploitable code in general subsystems. Unless you're referring to remote code execution, which in the era of ubiquitous web applications (often running involuntarily through advertisements, etc) seems like a distinction without a difference.

kllrnohj 5y ago
> And not via drivers, but userland-exploitable code in general subsystems. We're exclusively talking about the kernel+drivers here. User land exploits are irrelevant (and obviously not something fuchsia will be immune to). > Unless you're referring to remote code execution I'm referring to exploits that actually are found in the wild to have caused damage that a change in kernels would have done something to prevent.
- wahern 5y ago
  Drivers are the commercial case for Fuschia. But in general, microkernels make it much easier to 1) implement privilege isolation for subsystems and 2) implement subsystems in a more secure manner, both of which absolutely improve security posture. A subsystem is just another type of driver. Though, it depends on how well Zircon makes use of this--i.e. avoids implementing all the most critical subsystems in the same process, or otherwise abuses too much unprotected memory sharing among them.
  - kllrnohj 5y ago
    > 1) implement privilege isolation for subsystems and 2) implement subsystems in a more secure manner, both of which absolutely improve security posture. Sure, but Android already has that via a user per application for app sandboxing & a very extensive selinux policy set[1]. Which makes the real-world benefit of that seemingly very negligible. There's a huge gap between desktop Linux & Fuschia/Zircon here, but there doesn't seem to be a particularly big gap between Fuschia/Zircon & Android Linux. 1: See all the .te files in the public & prive dirs of https://cs.android.com/android/platform/superproject/+/master:system/sepolicy/ https://cs.android.com/android/platform/superproject/+/maste...

by wahern 5y ago

kllrnohj 5y ago

> And not via drivers, but userland-exploitable code in general subsystems. We're exclusively talking about the kernel+drivers here. User land exploits are irrelevant (and obviously not something fuchsia will be immune to). > Unless you're referring to remote code execution I'm referring to exploits that actually are found in the wild to have caused damage that a change in kernels would have done something to prevent.

wahern 5y ago
Drivers are the commercial case for Fuschia. But in general, microkernels make it much easier to 1) implement privilege isolation for subsystems and 2) implement subsystems in a more secure manner, both of which absolutely improve security posture. A subsystem is just another type of driver. Though, it depends on how well Zircon makes use of this--i.e. avoids implementing all the most critical subsystems in the same process, or otherwise abuses too much unprotected memory sharing among them.
- kllrnohj 5y ago
  > 1) implement privilege isolation for subsystems and 2) implement subsystems in a more secure manner, both of which absolutely improve security posture. Sure, but Android already has that via a user per application for app sandboxing & a very extensive selinux policy set[1]. Which makes the real-world benefit of that seemingly very negligible. There's a huge gap between desktop Linux & Fuschia/Zircon here, but there doesn't seem to be a particularly big gap between Fuschia/Zircon & Android Linux. 1: See all the .te files in the public & prive dirs of https://cs.android.com/android/platform/superproject/+/master:system/sepolicy/ https://cs.android.com/android/platform/superproject/+/maste...