4 ms·

> Linux kernel is simply not equipped to run trusted code and untrusted code in the same memory. Just for interest sake, is Linux better or worse than MacOS, i

> Linux kernel is simply not equipped to run trusted code and untrusted code in the same memory. Just for interest sake, is Linux better or worse than MacOS, iOS and Windows at this?

aseipp 4y ago
It's... complicated. Linux is just the kernel, but good modern OS security requires the kernel, the userspace, and the kernel/userspace boundary to all be hardened a significant amount. This means defense in depth, exploit mitigation, careful security and API boundaries put in place to separate components, etc. Until pretty recently (~3-4 years) Linux the kernel was actually pretty far behind in most respects versus competitors, including Windows and mac/iOS. I say this as someone who used to write a bunch of exploits as a hobby (mainly for Windows based systems and windows apps). But there's been a big increase in the amount of mitigations going into the kernel these days though. Most of the state of the art stuff was pioneered elsewhere from upstream but Linux does adopt more and more stuff these days. The userspace story is more of a mixed bag. Like, in reality, mobile platforms are far ahead here because they tend to enforce rigorous sandboxing far beyond the typical access control model in Unix or Windows. This is really important when you're running code under the same user. For example just because you run a browser and SSH as $USER doesn't mean your browser should access your SSH keys! But the unix model isn't very flexible for use cases like this unless you segregate every application into its own user namespace, which can come with other awkward consequences. In something like iOS for example, when an application needs a file and asks the user to pick one, the operating system will actually open a privileged file picker with elevated permissions, which can see all files, then only delegate those files the user selects to the app. Otherwise they simply can't see them. So there is a permission model here, and a delegation of permissions, that requires a significant amount of userspace plumbing. Things like FlatPak are improving the situation here (e.g XDG Portal APIs for file pickers, etc.) Userspace on general desktop platforms is moving very, very slowly here. If you want my honest opinion as someone who did security work and wrote exploits a lot: pretty much all of the modern systems are fundamentally flawed at the design level. They are composed of millions of lines of unsafe code that is incredibly difficult to audit and fix. Linux, the kernel, might actually be the worst offender in this case because while systems like iOS continue to move things out of the kernel (e.g. the iOS WiFi stack is now in userspace as of iOS 16 and the modem is behind an IOMMU) Linux doesn't really seem to be moving in this direction, and it increases in scope and features rapidly, so you need to be careful what you expose. It might actually be that the Linux kernel is possibly the weakest part of Android security these days for those reasons (just my speculation.) I mean you can basically just throw shit at the system call interface and find crashes, this is not a joke. Windows seems to be middle of the pack in this regard, but they do invest a lot in exploit mitigation and security, in no small part due to the notoriety of Windows insecurity in the XP days. Userspace is improving on all systems, in my experience, but it's a shitload of work to introduce new secure APIs and migrate things to use them, etc. Mobile platforms, both Android and iOS, are in general significantly further ahead here in terms of "What kind of blast radius can some application have if it is compromised", largely because the userspace was co-designed along with the security model. ChromeOS also qualifies IMO. So just pick your poison, and it's probably a step up over the average today. But they still are comprised using the same fundamental building blocks built on lots of unsafe code and dated APIs and assumptions. So there's an upper limit here on what you can do, I think. But we can still do a lot better even today. If you want something more open in the mobile sector, then probably the only one I would actually trust is probably GrapheneOS since its author (Daniel Micay) actually knows what he's doing when it comes to security mitigation and secure design. The FOSS world has a big problem IMO where people just think "security" means enabling some compiler flags and here's a dump of the source code, when that's barely the starting point -- and outside of some of the most scrutinized projects in the entire world, I would say FOSS security is often very very bad, and in my experience there's no indication FOSS actually generally improves security outside of those exceptional cases, but people hate hearing it. I suspect Daniel would agree with my assessment most of the fundamentals today are fatally flawed (including Linux) but, it is what it is.
lrvick 4y ago
Linux is a security shit show but it is at least publicly auditable, which is a prerequisite to form reasonably confidence in the security of software, or to rapidly correct mistakes found. OpenBSD by contrast has dual auditing and a stellar security reputation, but development is much slower and compatibility is very low. seL4 as an extreme is a micro-kernel with mathematically provable security by design, but no workstation software runs on it yet. MacOS, iOS, and Windows are proprietary so they are dramatically worse off than Linux in security out of the gate. No one should use these that desires to maximize freedom, security and privacy.
- snvzz 4y ago
  >seL4 as an extreme is a micro-kernel with mathematically provable security by design, but no workstation software runs on it yet. With Genode, POSIX compatibility is at the point where you can run a webkit2-derived browser natively. There is also 3d acceleration.
- px43 4y ago
  In the case of seL4, don't confuse formal verification with security. The code matches the spec, and security properties can be extracted very precisely, but spec might contain oversights/bugs which would allow an attacker to perform unexpected behaviors. If you define security as a "lack of exploitable bugs", then security can never be proven, because it's impossible to prove a negative. Also many formally verified systems have had critical bugs discovered, like the KRACK attacks in WPA. The formal verification wasn't wrong, just incomplete, because modeling complex systems is inherently an intractable problem. The fact that seL4 doesn't even offer bug bounties should be a huge red flag that this is still very much an academic exercise, and should not be used in places where security actually matters. https://github.com/seL4/seL4/blob/master/SECURITY.md https://github.com/seL4/seL4/blob/master/SECURITY.md
  - lrvick 4y ago
    > don't confuse formal verification with security It sure makes auditing that code conforms to an expected design a lot easier, which is most security bugs. This is a fantastic design choice for a security focused kernel. I will grant that proving something was implemented as designed does not rule out design flaws so, fair enough.
pjmlp 4y ago
Windows 10 and later run drivers and parts of the kernel on their own hypervisor slots. macOS has SIP. GNU/Linux is still not there doing this out of the box.
- ignoramous 4y ago
  I'm curious about your take on this. Would you say macOS, iOS, Windows are more trustable than FOSS OSes like Fuschia or ChromeOS, Android, or even QubeOS and Tails? If not, where else ChromiumOS / Android lack (keeping in mind the embedded nature of the latter)? How long do you think before viable open firmware / open hardware computing devices show up? Thanks.
  - pjmlp 4y ago
    Unpopular opinion, none of them. Because even for FOSS stuff, unless you are an expert on all levels of the stack you will not be able to assert there are some hidden exploits disguides as perfectly safe code. And if you have to rely on third parties to assert that for you, then you will have to trush their honesty and technical skills to be able to assert such statements. So there is only hope that all players are experts, don't do any mistakes, keep being honest, and exercise their certification for every new release for all products that make up a standard installation.

> Linux kernel is simply not equipped to run trusted code and untrusted code in the same memory. Just for interest sake, is Linux better or worse than MacOS, iOS and Windows at this?

aseipp 4y ago

It's... complicated. Linux is just the kernel, but good modern OS security requires the kernel, the userspace, and the kernel/userspace boundary to all be hardened a significant amount. This means defense in depth, exploit mitigation, careful security and API boundaries put in place to separate components, etc. Until pretty recently (~3-4 years) Linux the kernel was actually pretty far behind in most respects versus competitors, including Windows and mac/iOS. I say this as someone who used to write a bunch of exploits as a hobby (mainly for Windows based systems and windows apps). But there's been a big increase in the amount of mitigations going into the kernel these days though. Most of the state of the art stuff was pioneered elsewhere from upstream but Linux does adopt more and more stuff these days. The userspace story is more of a mixed bag. Like, in reality, mobile platforms are far ahead here because they tend to enforce rigorous sandboxing far beyond the typical access control model in Unix or Windows. This is really important when you're running code under the same user. For example just because you run a browser and SSH as $USER doesn't mean your browser should access your SSH keys! But the unix model isn't very flexible for use cases like this unless you segregate every application into its own user namespace, which can come with other awkward consequences. In something like iOS for example, when an application needs a file and asks the user to pick one, the operating system will actually open a privileged file picker with elevated permissions, which can see all files, then only delegate those files the user selects to the app. Otherwise they simply can't see them. So there is a permission model here, and a delegation of permissions, that requires a significant amount of userspace plumbing. Things like FlatPak are improving the situation here (e.g XDG Portal APIs for file pickers, etc.) Userspace on general desktop platforms is moving very, very slowly here. If you want my honest opinion as someone who did security work and wrote exploits a lot: pretty much all of the modern systems are fundamentally flawed at the design level. They are composed of millions of lines of unsafe code that is incredibly difficult to audit and fix. Linux, the kernel, might actually be the worst offender in this case because while systems like iOS continue to move things out of the kernel (e.g. the iOS WiFi stack is now in userspace as of iOS 16 and the modem is behind an IOMMU) Linux doesn't really seem to be moving in this direction, and it increases in scope and features rapidly, so you need to be careful what you expose. It might actually be that the Linux kernel is possibly the weakest part of Android security these days for those reasons (just my speculation.) I mean you can basically just throw shit at the system call interface and find crashes, this is not a joke. Windows seems to be middle of the pack in this regard, but they do invest a lot in exploit mitigation and security, in no small part due to the notoriety of Windows insecurity in the XP days. Userspace is improving on all systems, in my experience, but it's a shitload of work to introduce new secure APIs and migrate things to use them, etc. Mobile platforms, both Android and iOS, are in general significantly further ahead here in terms of "What kind of blast radius can some application have if it is compromised", largely because the userspace was co-designed along with the security model. ChromeOS also qualifies IMO. So just pick your poison, and it's probably a step up over the average today. But they still are comprised using the same fundamental building blocks built on lots of unsafe code and dated APIs and assumptions. So there's an upper limit here on what you can do, I think. But we can still do a lot better even today. If you want something more open in the mobile sector, then probably the only one I would actually trust is probably GrapheneOS since its author (Daniel Micay) actually knows what he's doing when it comes to security mitigation and secure design. The FOSS world has a big problem IMO where people just think "security" means enabling some compiler flags and here's a dump of the source code, when that's barely the starting point -- and outside of some of the most scrutinized projects in the entire world, I would say FOSS security is often very very bad, and in my experience there's no indication FOSS actually generally improves security outside of those exceptional cases, but people hate hearing it. I suspect Daniel would agree with my assessment most of the fundamentals today are fatally flawed (including Linux) but, it is what it is.

lrvick 4y ago

Linux is a security shit show but it is at least publicly auditable, which is a prerequisite to form reasonably confidence in the security of software, or to rapidly correct mistakes found. OpenBSD by contrast has dual auditing and a stellar security reputation, but development is much slower and compatibility is very low. seL4 as an extreme is a micro-kernel with mathematically provable security by design, but no workstation software runs on it yet. MacOS, iOS, and Windows are proprietary so they are dramatically worse off than Linux in security out of the gate. No one should use these that desires to maximize freedom, security and privacy.

snvzz 4y ago
>seL4 as an extreme is a micro-kernel with mathematically provable security by design, but no workstation software runs on it yet. With Genode, POSIX compatibility is at the point where you can run a webkit2-derived browser natively. There is also 3d acceleration.
px43 4y ago
In the case of seL4, don't confuse formal verification with security. The code matches the spec, and security properties can be extracted very precisely, but spec might contain oversights/bugs which would allow an attacker to perform unexpected behaviors. If you define security as a "lack of exploitable bugs", then security can never be proven, because it's impossible to prove a negative. Also many formally verified systems have had critical bugs discovered, like the KRACK attacks in WPA. The formal verification wasn't wrong, just incomplete, because modeling complex systems is inherently an intractable problem. The fact that seL4 doesn't even offer bug bounties should be a huge red flag that this is still very much an academic exercise, and should not be used in places where security actually matters. https://github.com/seL4/seL4/blob/master/SECURITY.md https://github.com/seL4/seL4/blob/master/SECURITY.md
- lrvick 4y ago
  > don't confuse formal verification with security It sure makes auditing that code conforms to an expected design a lot easier, which is most security bugs. This is a fantastic design choice for a security focused kernel. I will grant that proving something was implemented as designed does not rule out design flaws so, fair enough.

pjmlp 4y ago

Windows 10 and later run drivers and parts of the kernel on their own hypervisor slots. macOS has SIP. GNU/Linux is still not there doing this out of the box.

ignoramous 4y ago
I'm curious about your take on this. Would you say macOS, iOS, Windows are more trustable than FOSS OSes like Fuschia or ChromeOS, Android, or even QubeOS and Tails? If not, where else ChromiumOS / Android lack (keeping in mind the embedded nature of the latter)? How long do you think before viable open firmware / open hardware computing devices show up? Thanks.
- pjmlp 4y ago
  Unpopular opinion, none of them. Because even for FOSS stuff, unless you are an expert on all levels of the stack you will not be able to assert there are some hidden exploits disguides as perfectly safe code. And if you have to rely on third parties to assert that for you, then you will have to trush their honesty and technical skills to be able to assert such statements. So there is only hope that all players are experts, don't do any mistakes, keep being honest, and exercise their certification for every new release for all products that make up a standard installation.