4 ms·

IMO we have to step back and be honest that the Linux kernel is simply not equipped to run trusted code and untrusted code in the same memory. New bugs are foun

by lrvick 4y ago

IMO we have to step back and be honest that the Linux kernel is simply not equipped to run trusted code and untrusted code in the same memory. New bugs are found every few weeks. If history is of any guide Android and ChromiumOS likely still have many critical bugs the public does not know about yet. Sadly the only choice is to burn extra ram to give every security context a dedicated kernel and virtual machine. Hypervisors are the best sandbox that exists anchored down to a hardware IOMMU. QubesOS being VM based is thus the best effort secure workstation OS that exists atm. SpectrumOS looks promising as a potential next gen too.

flanked-evergl 4y ago
> 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.
mindslight 4y ago
I've never used Qubes. Rather I heavily segment with manually configured VMs. The ones that run proprietary software (eg webbrowsing, MSWin, etc) generally run on a different machine than my main desktop. It's quite convenient as I can go from my office to the couch, and I just open up the same VMs there and continue doing what I was doing. I define the network access for each VM in a spreasheet (local services and Internet horizon), which then gets translated into firewall rules. I can simultaneously display multiple web browsers, each with a different network nym (casual browsing, commercial VPN'd, TOR, etc). The downsides include needing an ethernet cable on my laptop (latency), and that this setup isn't great at going mobile. Eventually I'll get around to setting up a medium-trust laptop that runs a web browser and whatnot directly (while not having access to any keys to the kingdom), one of these days real soon now. Which brings me to the real downside is the work required to administer it - you already have to be in the self-hosting game. This is where an out-of-the-box solution could excel. Having recently become a NixOS convert, SpectrumOS looks very interesting!
- windexh8er 4y ago
  I used to leverage VMs more (and still do in certain cases) but I've moved to disposable/containerized by leveraging Kasm [0]. There's other ways to stream environments, but it's another option. Definitely check it out if you're looking for other options. [0] https://www.kasmweb.com https://www.kasmweb.com
- ThePowerOfFuet 4y ago
  Yeah, you should really look into Qubes.
- mtsr 4y ago
  Thinking of my kids' future has also made me much more energy-conscious. Meaning I've stopped running my VM host 24/7 like I was, because neither ESX nor Proxmox is really set up for saving energy easily (automated suspending and waking, etc). Which is a shame, since I'm actually finding that with gigabit fiber at home, even on mobile connections I can work pretty decently on homelab VMs. Running something like it on a laptop directly makes sense, but I worry about bringing some workloads back to my laptop that I really prefer to keep off it. In terms of raw performance my laptop isn't even close, especially with heavy graphic workloads. And then there's heat, etc.
teaearlgraycold 4y ago
To be fair, Pixels (and all modern Android phones by my understanding) use some kind of trusted execution environment. So if you have a Pixel 6 or later you're using Trusty to perform some trusted actions, which is not Linux and gets some of its own SoC die space. That doesn't mean you can't get kernel pwned and lose private info.
a-dub 4y ago
i think tanenbaum will be vindicated in the end. monolithic kernels are like 90s computer networks with perimeter security. if i were to guess, i'd guess that the future is microkernels with some sort of hardware accelerated secure message passing facility. zero-trust at kernel design scale.
- bjackman 4y ago
  I think many at Google would agree (https://fuchsia.dev/fuchsia-src/get-started/learn/intro/zircon https://fuchsia.dev/fuchsia-src/get-started/learn/intro/zirc...)
- mikewarot 4y ago
  Obligatory mention of capability based security goes here. We really need a way to run untrusted code and give it just the files we want, at run-time.
  - TeMPOraL 4y ago
    Obligatory reminder of the human angle here: we need also a way for untrusted code to not be able to nag the user into granting them extra permissions.
    - mikewarot 4y ago
      That's not capability based security, though everyone seems to think it is. (Perhaps it's just survivor bias effecting replies?) You never get nagged to take $5 out of your wallet to hand to an untrusted person, why should you get nagged to drop a file into an application you don't trust.
      - TeMPOraL 4y ago
        onSave() => fh1 = GetFileWritePerm($documents + "/project.foo"); fh2 = GetFileReadWritePerm($myFolder + "/cache.db"); while(!fh3) { fh3 = GetFileReadWritePerm("/etc/passwd"); }
andy_ppp 4y ago
I keep thinking about this too, everything should be containerised and you can control access to shared resources like the clipboard or file system with absolute certainty, even stopping certain app from access to anything.

by lrvick 4y ago

flanked-evergl 4y ago

> 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.

mindslight 4y ago

I've never used Qubes. Rather I heavily segment with manually configured VMs. The ones that run proprietary software (eg webbrowsing, MSWin, etc) generally run on a different machine than my main desktop. It's quite convenient as I can go from my office to the couch, and I just open up the same VMs there and continue doing what I was doing. I define the network access for each VM in a spreasheet (local services and Internet horizon), which then gets translated into firewall rules. I can simultaneously display multiple web browsers, each with a different network nym (casual browsing, commercial VPN'd, TOR, etc). The downsides include needing an ethernet cable on my laptop (latency), and that this setup isn't great at going mobile. Eventually I'll get around to setting up a medium-trust laptop that runs a web browser and whatnot directly (while not having access to any keys to the kingdom), one of these days real soon now. Which brings me to the real downside is the work required to administer it - you already have to be in the self-hosting game. This is where an out-of-the-box solution could excel. Having recently become a NixOS convert, SpectrumOS looks very interesting!

windexh8er 4y ago
I used to leverage VMs more (and still do in certain cases) but I've moved to disposable/containerized by leveraging Kasm [0]. There's other ways to stream environments, but it's another option. Definitely check it out if you're looking for other options. [0] https://www.kasmweb.com https://www.kasmweb.com
ThePowerOfFuet 4y ago
Yeah, you should really look into Qubes.
mtsr 4y ago
Thinking of my kids' future has also made me much more energy-conscious. Meaning I've stopped running my VM host 24/7 like I was, because neither ESX nor Proxmox is really set up for saving energy easily (automated suspending and waking, etc). Which is a shame, since I'm actually finding that with gigabit fiber at home, even on mobile connections I can work pretty decently on homelab VMs. Running something like it on a laptop directly makes sense, but I worry about bringing some workloads back to my laptop that I really prefer to keep off it. In terms of raw performance my laptop isn't even close, especially with heavy graphic workloads. And then there's heat, etc.

teaearlgraycold 4y ago

To be fair, Pixels (and all modern Android phones by my understanding) use some kind of trusted execution environment. So if you have a Pixel 6 or later you're using Trusty to perform some trusted actions, which is not Linux and gets some of its own SoC die space. That doesn't mean you can't get kernel pwned and lose private info.

a-dub 4y ago

i think tanenbaum will be vindicated in the end. monolithic kernels are like 90s computer networks with perimeter security. if i were to guess, i'd guess that the future is microkernels with some sort of hardware accelerated secure message passing facility. zero-trust at kernel design scale.

bjackman 4y ago
I think many at Google would agree (https://fuchsia.dev/fuchsia-src/get-started/learn/intro/zircon https://fuchsia.dev/fuchsia-src/get-started/learn/intro/zirc...)
mikewarot 4y ago
Obligatory mention of capability based security goes here. We really need a way to run untrusted code and give it just the files we want, at run-time.
- TeMPOraL 4y ago
  Obligatory reminder of the human angle here: we need also a way for untrusted code to not be able to nag the user into granting them extra permissions.
  - mikewarot 4y ago
    That's not capability based security, though everyone seems to think it is. (Perhaps it's just survivor bias effecting replies?) You never get nagged to take $5 out of your wallet to hand to an untrusted person, why should you get nagged to drop a file into an application you don't trust.
    - TeMPOraL 4y ago
      onSave() => fh1 = GetFileWritePerm($documents + "/project.foo"); fh2 = GetFileReadWritePerm($myFolder + "/cache.db"); while(!fh3) { fh3 = GetFileReadWritePerm("/etc/passwd"); }

andy_ppp 4y ago

I keep thinking about this too, everything should be containerised and you can control access to shared resources like the clipboard or file system with absolute certainty, even stopping certain app from access to anything.