7 ms·

Security is in terrible shape. Right now for power-consumers the most secure OSes for access control are GrapheneOS (AOSP) and Qubes OS. Windows (with privsep

Security is in terrible shape. Right now for power-consumers the most secure OSes for access control are GrapheneOS (AOSP) and Qubes OS. Windows (with privsep) and desktop Linux are (were) good at stopping drive-by printer driver installs but terrible at keeping your browser running rogue glowware exfiltrating blackmail to use against you (or planting felony charges to leverage). Qubes puts everything in boxes and you keep the spam and ham in separate boxes, and Graphene gives you Android's use of SELinux as well as Storage Scopes (it's like unveil()).

Borealid 3y ago
I wish I could use Graphene without needing to buy into their anti-OSS stance and ideology, though. The core idea is sound, but I frequently see: - MicroG is "insecure" because it requires "signature spoofing" (reality: LineageOS allows only MicroG to replace only Google Play Services - I wouldn't consider that "insecure" and the Graphene devs never explain further) - Open source software is less secure than closed source software (reality: mixed bag) - F-Droid is "insecure" (I can't address this one because I don't understand the point of view and I've never seen it clarified) - GrapheneOS executes Google Play Services in a "sandbox without any special permissions" (reality: there is a repository full of code that allows sandboxed Google Play to behave in a way other apps can't within the sandbox) - Automatically installing updates is necessary to "be secure" (reality: updates might add or remove vulnerabilities. Failing to update when a vulnerability exists is insecure, but updating automatically is not a clear win for a savvy, aware user) - System backups are not a part of a security policy (reality: having the ability to restore a backup is necessary to mitigate damage caused by an exploit) - Pixel devices are the only "sufficiently secure" phones (reality: it might be convenient targeting a single platform, but there are plenty of phones now that provide the technical capabilities Graphene requires) - Privacy is not part of security (reality: security is classic CIA - Confidentiality, Integrity, Availability. If you can't keep confidentiality you're missing one of the pillars) - Complying with Google's Compatibility Test Suite is "more secure" than deviating from it (reality: the CTS is designed to favor app developers over end users. The app developers might or might not be better at looking out for users' interests than the users themselves) Everything I'm representing as a GrapheneOS dev position I've heard straight from the horse's mouth on their forum and/or in their documentation. I think sometimes they hold opinions which aren't 100% aligned with what I'd consider a maximally secure system. That said, they have delivered a pretty solid OS if you can live with its various compromises. The one that really grates on me is the last one: I don't want an OS that chooses an app developer's "don't copy this file" flag over my desire to copy it! EDIT: formatting
- ementally 3y ago
  > F-Droid is "insecure" (I can't address this one because I don't understand the point of view and I've never seen it clarified) https://privsec.dev/posts/android/f-droid-security-issues/ https://privsec.dev/posts/android/f-droid-security-issues/
  - Borealid 3y ago
    I hadn't read that and it's informative. Let's paraphrase and dissect its arguments. > 1. F-Droid releases are signed with F-Droid keys, and Google Play releases are signed with Google Play and app developer keys both I don't feel this is an issue. Google is the party in exclusive control of which app developer keys are deemed valid, so the app developer signature adds exactly nothing. You either trust the channel to give you a correct application or you don't, and I think it's quite silly to implicitly suggest that end users would verify app signatures to notice a compromise of the app store they use. > from June to November of 2022, [F-Droid's] guest VM image officially ran an end-of-life release of Debian LTS This is in the past and not a strong argument. We don't know what individual app devs run on their build boxes - some of them are surely the devs' own laptops infected with malware, so this argument cuts more strongly against Google than for it. > While deterministic builds are a neat idea in theory, it requires the developer to make their toolchain match with what F-Droid provides This is straight-up dismissive bullshit. Reproducible builds are a valid alternative to signing the build output, and in my opinion superior as they guarantee you can actually build the app from its sources. The paragraph containing the explanation of why deterministic builds are a bad idea is the type of paragraph I was railing again when I wrote my previous comment: it undermines my faith in the Graphene devs' judgement. > 2. F-Droid app releases are slower and less frequent than Google Play releases Some apps update on F-Droid faster. This is mostly down to the app devs and the relative popularity of the two stores. The Graphene devs try to make the argument that there's something in the F-Droid build process that's not automatic, but so far as I know this is not true. Also, again, my point of view is that "faster updates" does not mean "more secure". If you quickly release a new vulnerability that's bad, so I'd rather have strong review of each new software version. > the fact that their build process is often broken using outdated tools This is bullshit sand-kicking, again. > 3. F-Droid allows users to install apps targeting lower Android SDK levels Users should be free, when informed, to do this. It's not a security problem. F-Droid displays the target SDK level. I don't think we should automatically consign all unmaintained software - and devices - to the graveyard in the name of security. > 4. We generally don't like the dev practices of the F-Droid maintainers Outdated information here again, talking about things F-Droid doesn't do any more like using jarsigner. If they wanted to say "we don't trust F-Droid to do the right thing" just say that and delete the rest of the page, but it's an opinion not some kind of factual stance. Or, you know, pick the particular problems you have with their practices, and then start supporting them instead of tearing them down when those problems are fixed. As they are now. > Their client also lacks TLS certificate pinning The client downloads apps and verifies their signature. This is the first argument I've seen here as legitimate, because although the problem is minor, connecting to the "wrong" store means you see the "wrong" versions of apps. But of course you couldn't use this to inject malicious code, because again, verified signatures. The devs on the page just say it could "lead to various security issues" which is overly vague for me to address more directly. > 5. The F-Droid client has a confusing UX Not a security issue. > 6. The F-Droid client has a confusing UX specifically about permissions Not a security issue. > Play Store restricts the use of highly invasive permissions such as MANAGE_EXTERNAL_STORAGE which allows apps to opt out of scoped storage if they can’t work with more privacy friendly approaches I should have the ability to install applications that work how I want them to work. Google shouldn't be able to prevent me from having a Gamecube emulator that stores its save files on my MicroSD card in a performant fashion. My overall verdict is that the page you linked (thanks) confirms my opinion of the GrapheneOS' developers stance: they choose a position, and then they throw together whatever arguments they can find that might be construed to support that position, regardless of merit. They intentionally use vague wording when they know the position they're supporting is weak, to instill fear in less-tech-savvy users who cannot sort the bullshit from the substance. It leaves me with the feeling they're not arguing in good faith.
DEADMINCE 3y ago
Graphene is nice but only works on Pixel hardware. e/OS is a good alternative. Qubes isn't really about access control so much as it is about having disposable vms for doing sensitive things.

Borealid 3y ago

I wish I could use Graphene without needing to buy into their anti-OSS stance and ideology, though. The core idea is sound, but I frequently see: - MicroG is "insecure" because it requires "signature spoofing" (reality: LineageOS allows only MicroG to replace only Google Play Services - I wouldn't consider that "insecure" and the Graphene devs never explain further) - Open source software is less secure than closed source software (reality: mixed bag) - F-Droid is "insecure" (I can't address this one because I don't understand the point of view and I've never seen it clarified) - GrapheneOS executes Google Play Services in a "sandbox without any special permissions" (reality: there is a repository full of code that allows sandboxed Google Play to behave in a way other apps can't within the sandbox) - Automatically installing updates is necessary to "be secure" (reality: updates might add or remove vulnerabilities. Failing to update when a vulnerability exists is insecure, but updating automatically is not a clear win for a savvy, aware user) - System backups are not a part of a security policy (reality: having the ability to restore a backup is necessary to mitigate damage caused by an exploit) - Pixel devices are the only "sufficiently secure" phones (reality: it might be convenient targeting a single platform, but there are plenty of phones now that provide the technical capabilities Graphene requires) - Privacy is not part of security (reality: security is classic CIA - Confidentiality, Integrity, Availability. If you can't keep confidentiality you're missing one of the pillars) - Complying with Google's Compatibility Test Suite is "more secure" than deviating from it (reality: the CTS is designed to favor app developers over end users. The app developers might or might not be better at looking out for users' interests than the users themselves) Everything I'm representing as a GrapheneOS dev position I've heard straight from the horse's mouth on their forum and/or in their documentation. I think sometimes they hold opinions which aren't 100% aligned with what I'd consider a maximally secure system. That said, they have delivered a pretty solid OS if you can live with its various compromises. The one that really grates on me is the last one: I don't want an OS that chooses an app developer's "don't copy this file" flag over my desire to copy it! EDIT: formatting

ementally 3y ago
> F-Droid is "insecure" (I can't address this one because I don't understand the point of view and I've never seen it clarified) https://privsec.dev/posts/android/f-droid-security-issues/ https://privsec.dev/posts/android/f-droid-security-issues/
- Borealid 3y ago
  I hadn't read that and it's informative. Let's paraphrase and dissect its arguments. > 1. F-Droid releases are signed with F-Droid keys, and Google Play releases are signed with Google Play and app developer keys both I don't feel this is an issue. Google is the party in exclusive control of which app developer keys are deemed valid, so the app developer signature adds exactly nothing. You either trust the channel to give you a correct application or you don't, and I think it's quite silly to implicitly suggest that end users would verify app signatures to notice a compromise of the app store they use. > from June to November of 2022, [F-Droid's] guest VM image officially ran an end-of-life release of Debian LTS This is in the past and not a strong argument. We don't know what individual app devs run on their build boxes - some of them are surely the devs' own laptops infected with malware, so this argument cuts more strongly against Google than for it. > While deterministic builds are a neat idea in theory, it requires the developer to make their toolchain match with what F-Droid provides This is straight-up dismissive bullshit. Reproducible builds are a valid alternative to signing the build output, and in my opinion superior as they guarantee you can actually build the app from its sources. The paragraph containing the explanation of why deterministic builds are a bad idea is the type of paragraph I was railing again when I wrote my previous comment: it undermines my faith in the Graphene devs' judgement. > 2. F-Droid app releases are slower and less frequent than Google Play releases Some apps update on F-Droid faster. This is mostly down to the app devs and the relative popularity of the two stores. The Graphene devs try to make the argument that there's something in the F-Droid build process that's not automatic, but so far as I know this is not true. Also, again, my point of view is that "faster updates" does not mean "more secure". If you quickly release a new vulnerability that's bad, so I'd rather have strong review of each new software version. > the fact that their build process is often broken using outdated tools This is bullshit sand-kicking, again. > 3. F-Droid allows users to install apps targeting lower Android SDK levels Users should be free, when informed, to do this. It's not a security problem. F-Droid displays the target SDK level. I don't think we should automatically consign all unmaintained software - and devices - to the graveyard in the name of security. > 4. We generally don't like the dev practices of the F-Droid maintainers Outdated information here again, talking about things F-Droid doesn't do any more like using jarsigner. If they wanted to say "we don't trust F-Droid to do the right thing" just say that and delete the rest of the page, but it's an opinion not some kind of factual stance. Or, you know, pick the particular problems you have with their practices, and then start supporting them instead of tearing them down when those problems are fixed. As they are now. > Their client also lacks TLS certificate pinning The client downloads apps and verifies their signature. This is the first argument I've seen here as legitimate, because although the problem is minor, connecting to the "wrong" store means you see the "wrong" versions of apps. But of course you couldn't use this to inject malicious code, because again, verified signatures. The devs on the page just say it could "lead to various security issues" which is overly vague for me to address more directly. > 5. The F-Droid client has a confusing UX Not a security issue. > 6. The F-Droid client has a confusing UX specifically about permissions Not a security issue. > Play Store restricts the use of highly invasive permissions such as MANAGE_EXTERNAL_STORAGE which allows apps to opt out of scoped storage if they can’t work with more privacy friendly approaches I should have the ability to install applications that work how I want them to work. Google shouldn't be able to prevent me from having a Gamecube emulator that stores its save files on my MicroSD card in a performant fashion. My overall verdict is that the page you linked (thanks) confirms my opinion of the GrapheneOS' developers stance: they choose a position, and then they throw together whatever arguments they can find that might be construed to support that position, regardless of merit. They intentionally use vague wording when they know the position they're supporting is weak, to instill fear in less-tech-savvy users who cannot sort the bullshit from the substance. It leaves me with the feeling they're not arguing in good faith.

DEADMINCE 3y ago

Graphene is nice but only works on Pixel hardware. e/OS is a good alternative. Qubes isn't really about access control so much as it is about having disposable vms for doing sensitive things.