SafetyNet, Play Integrity and Android Auto
GrapheneOS supports hardware attestation and has much stronger security than even the stock Pixel OS but isn't Google certified. Play Integrity and legacy SafetyNet Attestation check for Google certification, not any form of security. We have concrete plans to address this issue.
Due to hardware attestation and the support for it via the strong mode for Play Integrity and legacy SafetyNet Attestation, spoofing the Google certification checks is a lost cause over the long term. This is why we refrained from spoofing the much more commonly used basic mode.
Long term, the solution will be to convince organizations to support GrapheneOS by switching to directly using the hardware attestation API which has alternate OS support. See https://grapheneos.org/articles/attestation-compatibility-guide.
This is much easier to use now that there's an official library for it.
In the meantime, we've decided to work on spoofing the software certification checks due to greatly expanding adoption of this security theater. We could add a notification for apps using this telling users to ask the developers to do it in a better way, not Google certification.
We're aware that an SDK used by many banking apps has recently adopted the weak software Google certification checks. This has greatly increased the priority of a short term workaround. When we have time, we'll contact company making the SDK and some of the banks with our guide.
At some point, these SDKs are going to start using the strong mode and it's going to end the ability to spoof the checks. It's why we refrained from doing it because we know it's setting up events in the future where many apps suddenly lose compatibility from server side updates.
Extending our Sandboxed Google Play compatibility layer to support Android Auto is currently a top priority. It's nearly ready to ship, and after that the developer working on it will move on to a workaround for this to delay needing app developers or governments to solve it.
Someone had a thanksgiving moment like Ebeneezer Scrooge.
Love to see this stuff heart warming tale of the day. Glad everything worked out.
Recieved a zap without a message or notification here.
Thankyou to whoever it was.
LINUX WEB INSTALLER ISSUE AND WORKAROUND NOTICE
There's a bug in the fwupd service used by desktop Linux distributions causing the fastboot claim interface failure for our web installer and also similar failures for CLI fastboot. You can work around this by stopping fwupd such as with:
`systemctl stop [fwupd.service]`
(Remove square brackets. Had to add as Amethyst detects as link.)
This issue has unfortunately stopped MANY Linux users from successfully installing GrapheneOS. They've had to run the web installer on Windows, macOS or a Linux distribution without this issue such as ChromeOS or Android. Users on an OS like Arch Linux will often have added it.
There was also a similar bug in GVFS which appears to be resolved now. Many distributions freeze their packages for months or even years with only security bugs with a CVE assignment getting patched. These bugs have hindered adoption of GrapheneOS. It's hard to know how much.
It isn't yet available and is under development, demonstrated as part of another post outlining an element of our development roadmap post Android 14.
This preview is of App Communication Scopes from an incomplete proof of concept we made for a previous version. The goal is to provide the ability to disable communication with user installed apps within a profile with the ability to enable it on a case-by-case basis instead.
Honestly the first paragraph is appreciable. The latter is subjective, being knowledgable of what the project, moderation team suffers regularly, let alone being targeted as a public individual with far worse is truthfully objectively inaccurate.
Not something beyond that I'm willing to discuss as generally deteriorates into bad faith probing dragging the projects name into a manufactured circus.
Hit me up first thing if you encounter any problems, (you shouldn't but variables).
Looking forward to seeing your first post from a freshly flashed device.
Very interested to know how GrapheneOS is a bad standard?
Yeah this particular behaviour is an AOSP issue and not GrapheneOS specific.
If it failed to come back at all it would be hardware related.
There are numerous reports across the web of this issue happening due to hardware requiring RMA and repair on stock it really isn't likely to be software/OS related and coincidental as we aren't receiving mass reports back and dev/staff devices are unaffected.
For example:
https://www.reddit.com/r/GooglePixel/comments/rty3gq/pixel_6_pro_missing_fingerprint_options/
Meant 'and' not 'or'
I have 6a without issue, have you rebooted, is the FP gone from the lockscreen or the settings?
This in an owner or secondary user profile?
GrapheneOS version 2023111500 released:
https://grapheneos.org/releases#2023111500
See the linked release notes for a summary of the improvements over the previous release.
Forum discussion thread:
https://discuss.grapheneos.org/d/8923-grapheneos-version-2023111500-released
Vanadium version 119.0.6045.163.0 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/119.0.6045.163.0
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
You can run Vandium across multiple users, however Vanadium already has improved process based sandboxing architecture and site isolation, keeping web apps etc separate.
Read more here:
GrapheneOS Camera app version 64 released:
https://github.com/GrapheneOS/Camera/releases/tag/64
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
That's not right, at all and definitely not a GrapheneOS specific issue at all otherwise we'd be seeing a lot more feedback on it. Battery life across the board on GOS is either comparable to stock or better due to reduced system level footprint of no privileged Play Services.
As I've said elsewhere and I quote:
"I love hardware keys, passkeys etc, I appreciate the value proposition.
What I don't like is the centralisation by developers integrating them using Google/Apple API which don't sit outside of their invasive system services.
Sandboxed Play Services by GrapheneOS helps in this regard."
The ideal is to still see open implementations independent of Big Tech. You shouldn't need Google or Apple for accessing none Apple/Google services.
BRIEF OUTLINE OF THE GRAPHENEOS FEATURE ROADMAP
Take a look... π
In the near future, we plan to ship support for a per-app toggle for memory tagging, a per-app toggle for ptrace replacing the global one, duress PIN/password and a toggle for enabling Android Auto by granting a list of special privileges which can be reduced via shims over time.
We're also working on various other small features and initial work on some longer term projects including App Communication Scopes. In order to work on more at the same time, we need more developers, and we're currently moving forward with hiring additional full time developers.
This is a preview of App Communication Scopes from an incomplete proof of concept we made for a previous version. The goal is to provide the ability to disable communication with user installed apps within a profile with the ability to enable it on a case-by-case basis instead.
GrapheneOS already provides Contact Scopes and Storage Scopes as alternatives to granting apps contacts and media/storage permissions where apps will work without access to any of the user's data and the user grants it case-by-case. We plan to provide more features like these.
Our authoritative DNS nameservers now support DNS-over-TLS (DoT) with authentication via DANE TLSA and/or WebPKI. This allows DNS resolvers to make queries via securely encrypted connections. We're already seeing lots of DoT encrypted connections from multiple DNS providers.
Using DNS-over-TLS for authoritative DNS is bleeding edge and not widely supported yet. Cloudflare and most ISPs don't support this yet. Vast majority of the DNS-over-TLS connections are coming from Google Public DNS. There are only a small number of connections from elsewhere.
We're currently implementing this with an nginx TLS to TCP reverse proxy in front of PowerDNS.
https://github.com/GrapheneOS/infrastructure/commit/38bb002a019a0947c1b2c1bd0e7f5b602ae85f5c
https://github.com/GrapheneOS/ns1.grapheneos.org/commit/387f1027f8904fc148217a697fdad66d089c6cfc
This is a very forward-looking improvement. Google is the only major provider using it and only for opportunistic encryption right now.
MEMORY TAGGING (MTE) OUTLINE FOR GRAPHENEOS
GrapheneOS now has hardware memory tagging support in our Stable channel. Memory tagging greatly improves protection against targeted attacks. Thanks to hardware support on the Pixel 8 and Pixel 8 Pro, it's extremely low overhead despite the massive benefits it's able to provide.
GrapheneOS users on the Pixel 8 and Pixel 8 Pro can enable memory tagging via Settings β Security β More security settings β Advanced memory protection beta on supported devices. We'll be enabling it by default soon since we have a solid approach to preserve app compatibility.
We integrated it into hardened_malloc where it's able to provide stronger security properties than the experimental stock OS implementation.
Our current toggle enables it for everything other than Vanadium, vendor executables and user installed apps bundling native libraries.
We'll be enabling memory tagging support for Vanadium by default via the standard Chromium implementation.
For the near future, we'll be leaving memory tagging disabled by default for user installed apps bundling native libraries to avoid introducing a new compatibility issues.
It will be possible to enable memory tagging for all user installed apps with the ability to opt-out for specific apps where it causes issues. We want to eventually have it globally enabled by default, but we expect it to uncover a lot of issues hardened_malloc hasn't before.
It's also possible to use MTE for protecting from stack buffer overflows and use-after-scope by aligning and tagging variables with an escaping pointer. LLVM has an implementation of this and we've confirmed it works but it may not be optimized enough to enable it quite yet.
When fully integrated into the compiler and each heap allocator, MTE enforces a form of memory safety. It detects memory corruption as it happens. 4 bit tags limit it to probabilistic detection for the general case, but deterministic guarantees are possible via reserving tags.
In hardened_malloc, we deterministically prevent sequential overflows by excluding adjacent tags. We exclude a tag reserved for free tag and the previous tag used for the previous allocation in the slot to help with use-after-free detection alongside FIFO and random quarantines.
MTE support for protecting the Linux kernel isn't enabled yet, but we can likely enable that by default too. However, it's currently part of kasan and is more oriented towards debugging than hardening. It's not entirely clear that enabling it in the current state is a good idea.
OEM Unlock is permanently disabled for Verizon devices, other carriers require certain βplan/contract preconditions' be met before whitelisting the IMEI to enable it when connected via wifi.
Only SIM free devices or those from less restrictive carriers enable it OOTB.
However it seems like the US is worst for this with limited restrictions in Europe.
Might not be halloween, but still scares me how many companies rely on SMS for 2FA.
nostr:npub1gd3h5vg6zhcuy5a46crh32m4gjkx8xugu95wwgj2jqx55sfgxxpst7cn8c is who you may be thinking about?
Just think when considering your next device and alternate OS whether 'degoogle' or security is your focus or even both.
Choosing any other alternate OS and device comes with the decision to use a combination that is easier to compromise.
Or do you compromise on the 'degoogle' ideal on the vendor with Google hardware and pair it with the best in class no Google services by default GrapheneOS.
Which would you opt for?
Samsung Galaxy S23 was hacked twice on the first day of Torontoβs #Pwn2Own contest.
The device was running the latest Android software version and security patches.
Researchers also breached the Xiaomi 13 Proβs security measures twice.
#samsunggalaxys23 #xiaomi13 #infosec #cybersecgirl
https://www.androidauthority.com/galaxy-s23-hacked-pwn2own-3379226/
"While the Pixel 7 and iPhone 14 left unscathed"
There is a reason GrapheneOS uses the Pixel as it's foundation.
GRAPHENEOS ENABLES DISPLAY PORT ON 8TH GEN PIXELS:
Our next release for the Pixel 8 and Pixel 8 Pro will have DisplayPort output enabled now that we've tested it. The next release for these will also no longer be considered experimental but rather will be part of a regular production release alongside the other supported devices.