4 ms·

GrapheneOS developers keep insisting [0] that their security model is the only reasonably secure approach in the world, despite that Qubes OS proved that wrong.

GrapheneOS developers keep insisting [0] that their security model is the only reasonably secure approach in the world, despite that Qubes OS proved that wrong. https://news.ycombinator.com/item?id=45101400 https://news.ycombinator.com/item?id=45101400

ajjahs 1y ago
[dead]
ysnp 1y ago
>their security model is the only reasonably secure approach in the world They have not said anything like that. In fact there are plenty of things about the current GrapheneOS + Pixel end result that they would change if they had the resources and support to do so. They have repeatedly praised or highlighted improvements in iOS and other less mainstream operating systems. QubesOS is a completely different project with different goals and constraints. GrapheneOS have praised the isolation model of Qubes repeatedly, but have always said it is a strong approximation of many laptops. Older laptop operating systems (Windows/macOS/desktop Linux distros) do not aim to provide similar protections against threats that the newer mobile operating systems have done.
- strcat 1y ago
  See the response at https://news.ycombinator.com/item?id=45244398 https://news.ycombinator.com/item?id=45244398.
- fsflover 1y ago
  >> their security model is the only reasonably secure approach in the world >They have not said anything like that. Quote (https://news.ycombinator.com/item?id=30769666 https://news.ycombinator.com/item?id=30769666): > Librem 5 has incredibly poor hardware/firmware security and it isn't possible for us to work around that at a software level. It's missing the basic hardware and firmware security features that are required. The reality is that Librem 5 is secure according to a different threat model than the one GrapheneOS follows. This doesn't make it "incredibly" insecure, unless you believe that only you can define good threat models.
  - ysnp 1y ago
    Sorry, but it is very difficult to understand what you mean and what you want from GrapheneOS. GrapheneOS is a FOSS project and they have committed to that being the case for the forseeable future. They have expressed interest in open hardware, well-designed open source secure elements, open source blob-free firmware with proper signature verification, open source greenfield kernel and OS projects, hardware kill switches with a proper threat model etc. Why should anyone expect them to throw away everything they have accomplished to start several steps backward on platforms that don't achieve any of these things?
    - fsflover 1y ago
      > Why should anyone expect them to throw away everything I don't expect them to throw away anything. I just wanted to get a statement from them concerning what's a reasonable goal and what isn't. But still: - to break from their life-threatening dependence on Google? https://news.ycombinator.com/item?id=45208925 https://news.ycombinator.com/item?id=45208925; - to allow more people benefit from a better security, not just those who can afford a Pixel? > open source blob-free firmware Where did you find that? > open source greenfield kernel and OS projects I'm not sure what you're talking about but not GrapheneOS, which depends on a bunch of proprietary drivers and firmware. > hardware kill switches with a proper threat model Like those on Librem 5? Or do you mean some other device? I'm not aware of any other device with usable kill switches.
      - ysnp 1y ago
        >I just wanted to get a statement from them concerning what's a reasonable goal and what isn't Please contact the OEMs/manufacturers and ask them why they cannot support reasonable requirements like: minimum five years of full (OS, firmwared, security patches etc.) device support code, hardware accelerated virtualisation, isolated radios (Wi-Fi/Cellular/Bluetooth etc.), a decent secure element implementation and support for throttling, proper Wi-Fi privacy support etc. (https://grapheneos.org/faq#future-devices https://grapheneos.org/faq#future-devices) You are clearly passionate about this, and you are not alone. But I have never understood why people expect GrapheneOS to compromise their goals and values, rather than wanting others to improve to meet them. GrapheneOS is completely free. >to break from their life-threatening dependence on Google? They have had talks with at least one OEM in the years past before the recent round of communications, trying to secure support for GrapheneOS on non-Pixel hardware. They have had builds in the past for Samsung hardware and development boards to explore alternative platforms and interest in minimal blob platforms which they had to abandon because those were not suitable for the project long term. They have always been completely willing to support non-Pixel devices that meet their requirements, but none have been available or validated so far. It's not appropriate at all to say they have no interest in breaking their dependence on Google Pixels. Personally, I think it's bizarre that numerous companies like Fairphone, Punkt and OSOM can come and go without ever seriously attempting to meet the reasonable requirements set by GrapheneOS and offer alternative options. >to allow more people benefit from a better security, not just those who can afford a Pixel? GrapheneOS is not a hardware manufacturer with the benefits of economies of scale. If they could magically create an affordable device that met their standards they would do it... As you already understand, GrapheneOS is a project with limited resources. They put those resources to use in significantly improving the privacy/security for an operating system (OS) that guards regular people's most personal data and device. Any device they support that lowers that standard means much much more time spent on device support and much less time on important work that improves on what you can have now (GrapheneOS + Pixel 8 and above). GrapheneOS is also open source, so nothing stops you or I from adapting parts of it for a less suitable platform and releasing that for others to use. DivestOS for example used code and ideas from GrapheneOS in their own project, and GrapheneOS were always supportive of the project and even offered the founding developer a role in the development team after they stopped working on DivestOS. >Where did you find that? As I've said above, it is something they experimented with in the past. But the reality is that they are intimately familiar with some past and present projects around that area including Raptor Engineering stuff, SiFive, Betrusted, coreboot, OpenTitan, Tropic Square etc. GrapheneOS has always been deeply interested in quality open source software and open hardware, unfortunately they just never had opportunities to support those things while improving on the progress they have already made. >I'm not sure what you're talking about but not GrapheneOS, which depends on a bunch of proprietary drivers and firmware. I did not say Pixels are a blob-free platform. I said GrapheneOS have expressed interest in open source kernel and OS projects even outside of GrapheneOS itself. >Like those on Librem 5? Or do you mean some other device? I'm not aware of any other device with usable kill switches. No, I don't mean usability, I mean physical privacy switches with a proper threat model. GrapheneOS have stated they would be 100% interested in usable privacy switches for specific goals like stopping audio recording or location detection but it is a lower priority than other ideas they have to improve privacy/security on the device as a whole.
ranger_danger 1y ago
How did Qubes OS prove them wrong? You still have root on qubes, humans still make errors, IMO it's therefore technically still less secure. Of course this assumes your goal is to prevent bad things from happening in general, regardless of how it happens, and not just say "yea the OS is secure but humans can still mess things up by using it wrong". I think protecting people from themselves is a noble goal that is often overlooked, even if many will disagree with me.
- strcat 1y ago
  See the response at https://news.ycombinator.com/item?id=45244398 https://news.ycombinator.com/item?id=45244398.
- fsflover 1y ago
  > I think protecting people from themselves is a noble goal that is often overlooked, even if many will disagree with me. Indeed, this is where we disagree. "If you are protected by a steel door, but you don't have the key, you aren't safe: You're imprisoned." See also: https://news.ycombinator.com/item?id=45081344 https://news.ycombinator.com/item?id=45081344
IlikeKitties 1y ago
[flagged]
- strcat 1y ago
  See the response at https://news.ycombinator.com/item?id=45244398 https://news.ycombinator.com/item?id=45244398.
- fsflover 1y ago
  I explicitly said in the link that the lack of resources is a good reason for not supporting other devices, but it's not their stated main reason.
deleted 1y ago
[deleted]
hollerith 1y ago
Your link does not support the text in your comment.
- strcat 1y ago
  See the response at https://news.ycombinator.com/item?id=45244398 https://news.ycombinator.com/item?id=45244398.
- fsflover 1y ago
  https://news.ycombinator.com/item?id=45250815 https://news.ycombinator.com/item?id=45250815
strcat 1y ago
QubesOS provides strong compartmentalization between virtual machines defined by the user, but it doesn't provide better protection against exploitation within those guests. Network drivers are a special case due to running in a dedicated VM. Applications and guest operating systems are just as vulnerable to exploitation. They're not hardened operating systems but rather traditional desktop OSes with a weak privacy and security model. QubesOS similarly doesn't provide any significant protection against data extraction in the After First Unlock state. It's nearly entirely focused on compartmentalization at the granularity of a whole OS. GrapheneOS is focused on privacy and security overall including protecting applications and the OS from exploitation in general. GrapheneOS does use sandboxing and compartmentalization to improve security. Hardware-based virtualization is one of the GrapheneOS hardware requirements (https://grapheneos.org/faq#future-devices https://grapheneos.org/faq#future-devices) and is used through Android's virtualization framework. It's provided by pKVM on Pixels and Gunyah on Snapdragon. Making more use of virtualization beyond isolating system services via microdroid and running a desktop OS via Android's virtual machine management app (Terminal) is planned and being gradually worked on. It's part of what we work on overall, not the whole picture or primary focus. It will be a bigger focus over time as hardware improves to make it more viable. Smartphones didn't have a lot of memory for virtualization until recently and GrapheneOS needs memory for other protections too. The Pixel 6 was the first Pixel with CPU hardware virtualization support and the Pixel 10 is the first with native GPU hardware virtualization support not requiring proxying to the host for GPU acceleration. Secure GPU acceleration is quite important for making it into a highly usable feature, especially on a phone, so the hardware was not ready yet and still isn't on most other devices. QubesOS largely doesn't have that available either, but laptop or desktop hardware is more powerful.
- fsflover 1y ago
  > but it doesn't provide better protection against exploitation within those guests Why would you need that if you don't run any untrusted apps in a trusted VM? Also, you don't have any private information in the untrusted VMs. It might only be helpful in the context of security in depth, but this barrier for attackers is much lower than the virtualization itself. > data extraction in the After First Unlock state By whom? A physical attacker? > Hardware-based virtualization is one of the GrapheneOS hardware requirements Qubes doesn't force the user to have it. Could GrapheneOS also allow using devices which don't support it? It would make millions of people more secure, not less. And it would make GrapheneOS more popular, too. You could name it "GrapheneOS lite" if you're afraid of a false security message. > Applications and guest operating systems are just as vulnerable to exploitation Which exploitation? Where would it come from?
BLKNSLVR 1y ago
Even if that's true, it's not a knock against GrapheneOS itself. It's a subjective stance, not an objective one. This may be useful for some people to consider what projects they want to support, but it's not pertinent to discussions of function. I still enjoy Harry Potter despite controversy around what J.K. Rowling has said on some topics.

ajjahs 1y ago

[dead]

ysnp 1y ago

>their security model is the only reasonably secure approach in the world They have not said anything like that. In fact there are plenty of things about the current GrapheneOS + Pixel end result that they would change if they had the resources and support to do so. They have repeatedly praised or highlighted improvements in iOS and other less mainstream operating systems. QubesOS is a completely different project with different goals and constraints. GrapheneOS have praised the isolation model of Qubes repeatedly, but have always said it is a strong approximation of many laptops. Older laptop operating systems (Windows/macOS/desktop Linux distros) do not aim to provide similar protections against threats that the newer mobile operating systems have done.

strcat 1y ago
See the response at https://news.ycombinator.com/item?id=45244398 https://news.ycombinator.com/item?id=45244398.
fsflover 1y ago
>> their security model is the only reasonably secure approach in the world >They have not said anything like that. Quote (https://news.ycombinator.com/item?id=30769666 https://news.ycombinator.com/item?id=30769666): > Librem 5 has incredibly poor hardware/firmware security and it isn't possible for us to work around that at a software level. It's missing the basic hardware and firmware security features that are required. The reality is that Librem 5 is secure according to a different threat model than the one GrapheneOS follows. This doesn't make it "incredibly" insecure, unless you believe that only you can define good threat models.
- ysnp 1y ago
  Sorry, but it is very difficult to understand what you mean and what you want from GrapheneOS. GrapheneOS is a FOSS project and they have committed to that being the case for the forseeable future. They have expressed interest in open hardware, well-designed open source secure elements, open source blob-free firmware with proper signature verification, open source greenfield kernel and OS projects, hardware kill switches with a proper threat model etc. Why should anyone expect them to throw away everything they have accomplished to start several steps backward on platforms that don't achieve any of these things?
  - fsflover 1y ago
    > Why should anyone expect them to throw away everything I don't expect them to throw away anything. I just wanted to get a statement from them concerning what's a reasonable goal and what isn't. But still: - to break from their life-threatening dependence on Google? https://news.ycombinator.com/item?id=45208925 https://news.ycombinator.com/item?id=45208925; - to allow more people benefit from a better security, not just those who can afford a Pixel? > open source blob-free firmware Where did you find that? > open source greenfield kernel and OS projects I'm not sure what you're talking about but not GrapheneOS, which depends on a bunch of proprietary drivers and firmware. > hardware kill switches with a proper threat model Like those on Librem 5? Or do you mean some other device? I'm not aware of any other device with usable kill switches.
    - ysnp 1y ago
      >I just wanted to get a statement from them concerning what's a reasonable goal and what isn't Please contact the OEMs/manufacturers and ask them why they cannot support reasonable requirements like: minimum five years of full (OS, firmwared, security patches etc.) device support code, hardware accelerated virtualisation, isolated radios (Wi-Fi/Cellular/Bluetooth etc.), a decent secure element implementation and support for throttling, proper Wi-Fi privacy support etc. (https://grapheneos.org/faq#future-devices https://grapheneos.org/faq#future-devices) You are clearly passionate about this, and you are not alone. But I have never understood why people expect GrapheneOS to compromise their goals and values, rather than wanting others to improve to meet them. GrapheneOS is completely free. >to break from their life-threatening dependence on Google? They have had talks with at least one OEM in the years past before the recent round of communications, trying to secure support for GrapheneOS on non-Pixel hardware. They have had builds in the past for Samsung hardware and development boards to explore alternative platforms and interest in minimal blob platforms which they had to abandon because those were not suitable for the project long term. They have always been completely willing to support non-Pixel devices that meet their requirements, but none have been available or validated so far. It's not appropriate at all to say they have no interest in breaking their dependence on Google Pixels. Personally, I think it's bizarre that numerous companies like Fairphone, Punkt and OSOM can come and go without ever seriously attempting to meet the reasonable requirements set by GrapheneOS and offer alternative options. >to allow more people benefit from a better security, not just those who can afford a Pixel? GrapheneOS is not a hardware manufacturer with the benefits of economies of scale. If they could magically create an affordable device that met their standards they would do it... As you already understand, GrapheneOS is a project with limited resources. They put those resources to use in significantly improving the privacy/security for an operating system (OS) that guards regular people's most personal data and device. Any device they support that lowers that standard means much much more time spent on device support and much less time on important work that improves on what you can have now (GrapheneOS + Pixel 8 and above). GrapheneOS is also open source, so nothing stops you or I from adapting parts of it for a less suitable platform and releasing that for others to use. DivestOS for example used code and ideas from GrapheneOS in their own project, and GrapheneOS were always supportive of the project and even offered the founding developer a role in the development team after they stopped working on DivestOS. >Where did you find that? As I've said above, it is something they experimented with in the past. But the reality is that they are intimately familiar with some past and present projects around that area including Raptor Engineering stuff, SiFive, Betrusted, coreboot, OpenTitan, Tropic Square etc. GrapheneOS has always been deeply interested in quality open source software and open hardware, unfortunately they just never had opportunities to support those things while improving on the progress they have already made. >I'm not sure what you're talking about but not GrapheneOS, which depends on a bunch of proprietary drivers and firmware. I did not say Pixels are a blob-free platform. I said GrapheneOS have expressed interest in open source kernel and OS projects even outside of GrapheneOS itself. >Like those on Librem 5? Or do you mean some other device? I'm not aware of any other device with usable kill switches. No, I don't mean usability, I mean physical privacy switches with a proper threat model. GrapheneOS have stated they would be 100% interested in usable privacy switches for specific goals like stopping audio recording or location detection but it is a lower priority than other ideas they have to improve privacy/security on the device as a whole.

ranger_danger 1y ago

How did Qubes OS prove them wrong? You still have root on qubes, humans still make errors, IMO it's therefore technically still less secure. Of course this assumes your goal is to prevent bad things from happening in general, regardless of how it happens, and not just say "yea the OS is secure but humans can still mess things up by using it wrong". I think protecting people from themselves is a noble goal that is often overlooked, even if many will disagree with me.

strcat 1y ago
See the response at https://news.ycombinator.com/item?id=45244398 https://news.ycombinator.com/item?id=45244398.
fsflover 1y ago
> I think protecting people from themselves is a noble goal that is often overlooked, even if many will disagree with me. Indeed, this is where we disagree. "If you are protected by a steel door, but you don't have the key, you aren't safe: You're imprisoned." See also: https://news.ycombinator.com/item?id=45081344 https://news.ycombinator.com/item?id=45081344

IlikeKitties 1y ago

[flagged]

strcat 1y ago
See the response at https://news.ycombinator.com/item?id=45244398 https://news.ycombinator.com/item?id=45244398.
fsflover 1y ago
I explicitly said in the link that the lack of resources is a good reason for not supporting other devices, but it's not their stated main reason.

deleted 1y ago

[deleted]

hollerith 1y ago

Your link does not support the text in your comment.

strcat 1y ago
See the response at https://news.ycombinator.com/item?id=45244398 https://news.ycombinator.com/item?id=45244398.
fsflover 1y ago
https://news.ycombinator.com/item?id=45250815 https://news.ycombinator.com/item?id=45250815

strcat 1y ago

QubesOS provides strong compartmentalization between virtual machines defined by the user, but it doesn't provide better protection against exploitation within those guests. Network drivers are a special case due to running in a dedicated VM. Applications and guest operating systems are just as vulnerable to exploitation. They're not hardened operating systems but rather traditional desktop OSes with a weak privacy and security model. QubesOS similarly doesn't provide any significant protection against data extraction in the After First Unlock state. It's nearly entirely focused on compartmentalization at the granularity of a whole OS. GrapheneOS is focused on privacy and security overall including protecting applications and the OS from exploitation in general. GrapheneOS does use sandboxing and compartmentalization to improve security. Hardware-based virtualization is one of the GrapheneOS hardware requirements (https://grapheneos.org/faq#future-devices https://grapheneos.org/faq#future-devices) and is used through Android's virtualization framework. It's provided by pKVM on Pixels and Gunyah on Snapdragon. Making more use of virtualization beyond isolating system services via microdroid and running a desktop OS via Android's virtual machine management app (Terminal) is planned and being gradually worked on. It's part of what we work on overall, not the whole picture or primary focus. It will be a bigger focus over time as hardware improves to make it more viable. Smartphones didn't have a lot of memory for virtualization until recently and GrapheneOS needs memory for other protections too. The Pixel 6 was the first Pixel with CPU hardware virtualization support and the Pixel 10 is the first with native GPU hardware virtualization support not requiring proxying to the host for GPU acceleration. Secure GPU acceleration is quite important for making it into a highly usable feature, especially on a phone, so the hardware was not ready yet and still isn't on most other devices. QubesOS largely doesn't have that available either, but laptop or desktop hardware is more powerful.

fsflover 1y ago
> but it doesn't provide better protection against exploitation within those guests Why would you need that if you don't run any untrusted apps in a trusted VM? Also, you don't have any private information in the untrusted VMs. It might only be helpful in the context of security in depth, but this barrier for attackers is much lower than the virtualization itself. > data extraction in the After First Unlock state By whom? A physical attacker? > Hardware-based virtualization is one of the GrapheneOS hardware requirements Qubes doesn't force the user to have it. Could GrapheneOS also allow using devices which don't support it? It would make millions of people more secure, not less. And it would make GrapheneOS more popular, too. You could name it "GrapheneOS lite" if you're afraid of a false security message. > Applications and guest operating systems are just as vulnerable to exploitation Which exploitation? Where would it come from?

BLKNSLVR 1y ago

Even if that's true, it's not a knock against GrapheneOS itself. It's a subjective stance, not an objective one. This may be useful for some people to consider what projects they want to support, but it's not pertinent to discussions of function. I still enjoy Harry Potter despite controversy around what J.K. Rowling has said on some topics.