3 ms·

> massive risk Are you saying that the Qubes OS security model is worse than the GrapheneOS one?

IlikeKitties 1y ago
It's a different approach to compartmentalization and the security risk of root in Grapheneos is different to that in QubesOS. But you know this looking at your bio, you just chose to ignore it.
- fsflover 1y ago
  Can you elaborate on the differences in the compartmentalization? When the existence of root is equivalent to a broken security, it doesn't look secure to me at all. Are you talking about the security from the user? By the way, personal attacks are against the HN Guidelines.
  - IlikeKitties 1y ago
    Ah yes thats a real good faith argument you got there. GrapheneOS is designed so you don’t need root to run apps or manage the device. Compartmentalization is on an per app level. And you already know how qubes does compartmentalisation.
    - strcat 1y ago
      Sandboxing is on a per-app level but those sandboxed apps can be hooked up to different profiles. The Linux kernel is the main weakness of the current app sandboxing along with system services to a lesser extent. Running apps or groups of apps within virtual machines is definitely part of what GrapheneOS working on. There's already hardware-based virtualization integration but it really needs native GPU virtualization support to be fully usable for GUI usage without relying on proxying GPU commands to the host OS. Pixel 10 is the first device with this, but it will take us some time to support the 10th gen Pixels and our focus is going to be more on Snapdragon devices and their Gunyah hypervisor soon due to our OEM partnership.
      - fsflover 1y ago
        > Running apps or groups of apps within virtual machines is definitely part of what GrapheneOS working on This sounds like a great news to me, thank you.
subscribed 1y ago
Non sequitur? GOS is not running a flavour of mainline Linux, but Android. They're nevertheless planning on moving to virtualisation as well https://discuss.grapheneos.org/d/24154-grapheneoss-roadmap-regarding-virtualization https://discuss.grapheneos.org/d/24154-grapheneoss-roadmap-r... For now it's as good as it gets.
- strcat 1y ago
  Linux doesn't mean systemd, GNU coreutils, glibc, GCC, GNU binutils, GNOME, etc. GrapheneOS is a Linux distribution and supports the Linux 6.1, 6.6 or 6.12 LTS branches. 6.12 is the latest LTS branch. Using Linux is a pragmatic thing, not a positive one for privacy or security. A huge monolithic kernel written in C is not the future for a highly secure OS. Moving away from the Linux kernel is important. QubesOS exists as a workaround for the insecurity of Linux. If the OS was using a highly secure microkernel in the first place, their hardware virtualization approach wouldn't be needed.
  - fsflover 1y ago
    > If the OS was using a highly secure microkernel in the first place, their hardware virtualization approach wouldn't be needed. Do you have any statistics to show about how secure a micro-kernel is? I can't believe it can be better than this: https://www.qubes-os.org/security/qsb/ https://www.qubes-os.org/security/qsb/
    - deleted 1y ago
      [deleted]
    - strcat 1y ago
      Xen itself is a microkernel. The list of vulnerabilities you've linked has a very limited scope not accounting for most vulnerabilities impacting QubesOS users. It also isn't a complete list for that limited scope. However, what you've linked shows the benefit of a microkernel-based design and why it would be best to have it beyond a hypervisor but rather inside of the virtual machines too. The vulnerabilities impacting the kernel and applications within the virtual machines are still very relevant to QubesOS users. QubesOS protects well against an attacker escaping from a virtual machine, but does not protect against an attacker exploiting the OS or applications within the virtual machines. An attacker can do cross-guest exploits via the network too, which would not be considered within the scope of that list. As an example, if an attacker could exploit the network VM via a Linux kernel TCP/IP vulnerability, then exploit connected virtual machines from there with the same vulnerability. Network driver vulnerabilities are another way to get that initial foothold. It wouldn't be a hole in the architecture implemented by QubesOS but it would still give them control over everything that matters to the user.

It's a different approach to compartmentalization and the security risk of root in Grapheneos is different to that in QubesOS. But you know this looking at your bio, you just chose to ignore it.

fsflover 1y ago
Can you elaborate on the differences in the compartmentalization? When the existence of root is equivalent to a broken security, it doesn't look secure to me at all. Are you talking about the security from the user? By the way, personal attacks are against the HN Guidelines.
- IlikeKitties 1y ago
  Ah yes thats a real good faith argument you got there. GrapheneOS is designed so you don’t need root to run apps or manage the device. Compartmentalization is on an per app level. And you already know how qubes does compartmentalisation.
  - strcat 1y ago
    Sandboxing is on a per-app level but those sandboxed apps can be hooked up to different profiles. The Linux kernel is the main weakness of the current app sandboxing along with system services to a lesser extent. Running apps or groups of apps within virtual machines is definitely part of what GrapheneOS working on. There's already hardware-based virtualization integration but it really needs native GPU virtualization support to be fully usable for GUI usage without relying on proxying GPU commands to the host OS. Pixel 10 is the first device with this, but it will take us some time to support the 10th gen Pixels and our focus is going to be more on Snapdragon devices and their Gunyah hypervisor soon due to our OEM partnership.
    - fsflover 1y ago
      > Running apps or groups of apps within virtual machines is definitely part of what GrapheneOS working on This sounds like a great news to me, thank you.

subscribed 1y ago

Non sequitur? GOS is not running a flavour of mainline Linux, but Android. They're nevertheless planning on moving to virtualisation as well https://discuss.grapheneos.org/d/24154-grapheneoss-roadmap-regarding-virtualization https://discuss.grapheneos.org/d/24154-grapheneoss-roadmap-r... For now it's as good as it gets.

strcat 1y ago
Linux doesn't mean systemd, GNU coreutils, glibc, GCC, GNU binutils, GNOME, etc. GrapheneOS is a Linux distribution and supports the Linux 6.1, 6.6 or 6.12 LTS branches. 6.12 is the latest LTS branch. Using Linux is a pragmatic thing, not a positive one for privacy or security. A huge monolithic kernel written in C is not the future for a highly secure OS. Moving away from the Linux kernel is important. QubesOS exists as a workaround for the insecurity of Linux. If the OS was using a highly secure microkernel in the first place, their hardware virtualization approach wouldn't be needed.
- fsflover 1y ago
  > If the OS was using a highly secure microkernel in the first place, their hardware virtualization approach wouldn't be needed. Do you have any statistics to show about how secure a micro-kernel is? I can't believe it can be better than this: https://www.qubes-os.org/security/qsb/ https://www.qubes-os.org/security/qsb/
  - deleted 1y ago
    [deleted]
  - strcat 1y ago
    Xen itself is a microkernel. The list of vulnerabilities you've linked has a very limited scope not accounting for most vulnerabilities impacting QubesOS users. It also isn't a complete list for that limited scope. However, what you've linked shows the benefit of a microkernel-based design and why it would be best to have it beyond a hypervisor but rather inside of the virtual machines too. The vulnerabilities impacting the kernel and applications within the virtual machines are still very relevant to QubesOS users. QubesOS protects well against an attacker escaping from a virtual machine, but does not protect against an attacker exploiting the OS or applications within the virtual machines. An attacker can do cross-guest exploits via the network too, which would not be considered within the scope of that list. As an example, if an attacker could exploit the network VM via a Linux kernel TCP/IP vulnerability, then exploit connected virtual machines from there with the same vulnerability. Network driver vulnerabilities are another way to get that initial foothold. It wouldn't be a hole in the architecture implemented by QubesOS but it would still give them control over everything that matters to the user.