Live data from Hacker News

GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

grapheneos.org

11–20 of 186 posts

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#11
post #9

Earlier quoted context omitted.

Don’t even those phones feature a cellular modem that shares memory with the CPU? In that case, they remain insecure.

May have been an issue in the past. Daniel claims that modern Pixel devices (among others) use IOMMU to control which memory segments the baseband device can access, and if implemented correctly it should only allow what is necessary for device->driver communication. I do think more research is needed.

I was pretty amazed when I bought an MR200 lte-capable router that the LTE module actually runs its own personal Android discrete from the router cpu.

https://openwrt.org/toh/tp-link/archer-mr200#the_lte_modem

Of course that has never and will never receive any security updates. So although iommu isolation is good, it may not help much if there's a whole other OS hacked that can initiate its own network connections and futz with any traffic, eg, deny main OS updates until it can attack it via an unpatched vuln. TLS is good but it'd only take one hhtp connection through unpatched webview.

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#12
post #3

A very condensed version of the messy CopperheadOS implosion is: https://en.wikipedia.org/wiki/CopperheadOS#History It's good that the tech person is moving on, but Android doesn't seem a great starting point if privacy&security are the top priorities (as opposed to remaining captive in the Android camp, with some belief that you're a bit more secure than default).

I always wondered what the backstory was there, but the internet is one of those places where if I heard to the real story I don't know if I'd know enough to belive it.

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#13

Librem seems to have the correct way forward, reject the big mess of Android and catch up to it with completely Open pieces. https://puri.sm/products/librem-5/ They're making good progress and I can't wait to be able to update my handheld device with mainline pieces for as long as anyone who still uses one cares to update it. Currently my Samsung Android device is at Dec 2018 patchlevel and nothing I can do about it.

Librem 5 isn't going to be particularly security-focused: no attestation, no trusted boot, most userspace programs are written in memory unsafe languages like C, with no extra effort memory corruption mitigations. Also, Flatpak offers a permission system that's very limited compared to Android.

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#14

Librem seems to have the correct way forward, reject the big mess of Android and catch up to it with completely Open pieces. https://puri.sm/products/librem-5/ They're making good progress and I can't wait to be able to update my handheld device with mainline pieces for as long as anyone who still uses one cares to update it. Currently my Samsung Android device is at Dec 2018 patchlevel and nothing I can do about it.

Librem 5 isn't going to be particularly security-focused: no attestation, no trusted boot, most userspace programs are written in memory unsafe languages like C, with no extra effort memory corruption mitigations. Also, Flatpak offers a permission system that's very limited compared to Android.

I guess that's because they know that Chain-of-trust only gets you so far.

Eventually you're running something big with bug after bug found every month and and an attack surface that includes the local filesystem and the network. At that point the buzzwords make no difference.

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#15

Earlier quoted context omitted.

Librem 5 isn't going to be particularly security-focused: no attestation, no trusted boot, most userspace programs are written in memory unsafe languages like C, with no extra effort memory corruption mitigations. Also, Flatpak offers a permission system that's very limited compared to Android.

I guess that's because they know that Chain-of-trust only gets you so far. Eventually you're running something big with bug after bug found every month and and an attack surface that includes the local filesystem and the network. At that point the buzzwords make no difference.

Chain of trust does protect you from evil maid attacks. And yes, there can be bugs in application layer, but at least half of all CVEs are memory corruption bugs.

These practices do offer a massive reduction in attack surface. You seem to argue it doesn't matter since it doesn't eliminate attack surface completely.

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#16

Earlier quoted context omitted.

Librem 5 isn't going to be particularly security-focused: no attestation, no trusted boot, most userspace programs are written in memory unsafe languages like C, with no extra effort memory corruption mitigations. Also, Flatpak offers a permission system that's very limited compared to Android.

I guess that's because they know that Chain-of-trust only gets you so far. Eventually you're running something big with bug after bug found every month and and an attack surface that includes the local filesystem and the network. At that point the buzzwords make no difference.

Chain of trust won't reduce the attack surface, but adopting memory corruption mitigations and replacing C code with something with stronger memory-protection guarantees would -- and while some kinds of memory protection can be bolted on later with minimal disruption, minimizing C is best done from the start.

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#17

Creator of CopperheadOS [0] and now GrapheneOS, Daniel Micay, was a prolific contributor to rustlang-core [1] but did rub off the rustlang community the wrong way? If I'm not mistaken he has a history of contributing to Arch Linux, as well. What happened with CopperheadOS was unfortunate [2]. I hope Daniel [3] is able to work on GrapheneOS on his own terms [4]. The work that was done had garnered a lot of following a…

He's also the author of Termite[0]. Pretty impressive how many projects he's been involved with.

[0] https://github.com/thestinger/termite

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#18

Librem seems to have the correct way forward, reject the big mess of Android and catch up to it with completely Open pieces. https://puri.sm/products/librem-5/ They're making good progress and I can't wait to be able to update my handheld device with mainline pieces for as long as anyone who still uses one cares to update it. Currently my Samsung Android device is at Dec 2018 patchlevel and nothing I can do about it.

Indeed. I'm tired of each new attempt to fix Android and make it usable and safe. Apps written for Android are written to work with Google's expectations and assume the presence of Google's servers and proprietary APIs, and that's getting worse, not better.

Librem is going the right way, and there are a handful of other companies working along the same path. Necunos is another I heard of as well: https://necunos.com/community/

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#19

Earlier quoted context omitted.

From the link- "In the current early stage of the project, GrapheneOS provides production releases for the Pixel, Pixel XL, Pixel 2, Pixel 2 XL, Pixel 3 and Pixel 3 XL. It will support other devices in the future, but devices are carefully chosen based on their merits rather than the project aiming to have broad device support. Broad device support is counter to the aims of the project, and the project will eventuall…

Don’t even those phones feature a cellular modem that shares memory with the CPU? In that case, they remain insecure.

A component being on the same die as the CPU doesn't mean that it isn't isolated. The SoC components in Snapdragon chips have IOMMU isolation. In modern computers, including smartphones, there are many components inside and outside SoC with memory access. A component being on the SoC is orthogonal to whether it has direct memory access. Direct memory access is supposed to be contained properly by an IOMMU, and that's the case for most of the components in the devices targeted by GrapheneOS. It's one of many kinds of hardware / firmware security properties that's going to play a substantial role in researching and choosing devices as targets.

Research is currently ongoing into choosing at least one decent low-end device with the least security compromises. There's no way to avoid losing some of the fancier hardware security features like the HSM because they aren't offered. The expectation is still that all the basic hardware / firmware security features are intact, which includes a decent IOMMU implementation, verified boot / attestation, at least a TEE-based hardware keystore (if they don't have a nicer HSM implementation like the high-end targets), etc. Many of the baseline security properties are tied to the SoC, including the IOMMU implementation for SoC components. Device vendors and the peripheral hardware vendors (like Broadcom for Wi-Fi) end up responsible for properly setting up IOMMU containment for peripherals, and that's often where the ball is completely dropped. There are often problems tied to where there are boundaries between organizations because there's often a lack of responsibility taken for these things. SoC security is unavoidably something that the SoC companies are responsible for handling, but issues like properly containing the Wi-Fi SoC can end up relegated to being treated as someone else's problem by every company involved.

Re: GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

#20

Earlier quoted context omitted.

I guess that's because they know that Chain-of-trust only gets you so far. Eventually you're running something big with bug after bug found every month and and an attack surface that includes the local filesystem and the network. At that point the buzzwords make no difference.

Chain of trust does protect you from evil maid attacks. And yes, there can be bugs in application layer, but at least half of all CVEs are memory corruption bugs. These practices do offer a massive reduction in attack surface. You seem to argue it doesn't matter since it doesn't eliminate attack surface completely.

No, chain-of-trust only has one trick... it can check that what you're about to run is unaltered from what was signed to some degree of probability.

If that is the - shipped and validly signed - bugridden nightmare-fuel like the propreitary Qualcomm 802.11 stack or proprietary multimedia bits that are a rich and continuous source of vulnerabilities (take a look through the last months here https://source.android.com/security/bulletin/2019-06-01 ) all the buzzwords did was ensure the vulnerable version is running so it can be exploited. The evil maid can get in that way.

Librem's security model is that of a Linux box, signed update packages... it's not a panacea against hacks but nor are the buzzwords you mentioned. At least they're trying to eliminate the really dangerous proprietary pieces that constantly provide new vulns.

Post reply on HN