flawedworld

  • Joined Jun 9, 2022
  • Because these distros usually are stuck on years old packages from the start of the duration of their existence. It is a key problem of modern OS engineering if you ask me. It applies to all packages on these distros typically, with very few exceptions.

  • Recently, when I put my carrier's SIM card in, I noticed that a new app had been installed automatically

    It wasn't installed. The "SIM Toolkit" app is part of AOSP, and is part of GrapheneOS. It is a frontend for STK applications on your SIM card. The app is disabled by default, and only is enabled if your carrier has applications which expose support for STK apps to the OS from your SIM card.

    I find it rather amusing that even in this OS, where security is the utmost priority, the carrier can override all the protection in place and install their own untrusted code on my phone.

    See my prior comment.

    what was the rationale behind not letting users uninstall carrier apps. Better yet, why are they installed on their own in the first place?

    See my prior comment.

    Is there actually any assurance that the carrier won't install a RAT? (other than the fact that I am not a person of interest to the state)

    Carriers cannot install apps into GrapheneOS, We don't ship with any support for OMA-DM apps (device management system which can be used by carriers, it is used on Verizon in the US) and no 3rd party carrier apps (e.g. the Verizon app) at all are built into the OS. unlike the stock OS, which does ship them (this extends to the OMA-DM apps too to be clear).

    Now for the highly unlikely (really must stress that part) but interesting part. The carrier (or someone with enough privileges at your carrier) could run arbitrary code on your SIM card (To make it super clear: said code is not running in the Android OS) via JavaCard applets (which is how you implement STK applets). This is how SIM cards work, it is part of the trust you place into your carrier. STK doesn't give any access into the Android OS to the carrier. An adversary could in theory gain access one way or another to run their malicious code on your SIM card, but they would be confined to the SIM card, so they can only "touch" the baseband, and the data/information passing through it. This though is pretty much the same data/information the carrier (or someone with enough privileges at your carrier) could also be able to obtain without needing the ability to run arbitrary code on your SIM card. All of the above applies to eSIMs and iSIMs too.

    Hope that is clear. Let me know if you have more questions.

    • Try on the normal Pixel OS, it is unlikely that this is an issue with GrapheneOS. Note: GrapheneOS Camera does not support external audio recording devices.

      • It is an app issue if the app forbids using the user trust store.

        • You can install a user certificate as you would on any other Android OS.

          • The behaviour will be the same as on the stock OS, it's likely that you did not test it on Android 14 on the stock OS. The app probably just has not updated for Android 14.

          • The alerts are private, there is no issue to be had.

          • It will work fine. GrapheneOS supports the alerts perfectly fine.

          • pipe2null

            pipe2null Another important big picture issue. Is it reasonable to equate "verified boot" with x86/64 efi secure boot, or is that a gross mischaracterization? Certs exist in mobo firmware, firmware checks efi executable's signatures prior to executing, signed executables are required to check signatures for any chainloaded execs/kernels, etc?

            It is nothing like the UEFI Secure Boot you see on x86_64. The boot chain on a properly configured Android device verifies the bootloader, firmware, and all OS partitions (this includes the kernel, userspace etc). It is a massively important security feature.

            pipe2null Which brings us to my OP. If a fork of GOS was able to reasonably support one or more cheap aliexpress devices, then a small company or even just a single dev could import for cheap, install psuedo-GOS, mark up the price to cover the work plus basic tech support, and still sell it at a pricepoint that is competitive enough for people to take a chance on a no-name company/person selling devices running a virtually unknown-to-normal-folk niche OS.

            This would be massively harmful. You can't paint over the architectural security issues of a broken, insecure device by just changing the OS on it. It would mislead users and cause substantial harm to them.

          • kenmacd Hardware security features and proper SoC configuration are critical to having a secure platform.

            A few notable things Pixels get right and have:

            • Proper non-broken configuration of IOMMUs
            • Non-broken AVB 2.0 (Android Verified Boot) support, with non-broken support for user defined root of trust (critical for running your own OS)
            • A dedicated hardware secure element (In newer Pixels, this is the Titan M2) which provides..
              -- The Weaver API, without this the device encryption sucks pretty much, it provides brute force resistance
              -- Hardware KeyStore support - allows for storing secrets in secure element
            • Modern TEE implementation running Trusty, which assists in brute force resistance
            • Full AOSP support with device trees, drivers, HALs etc all ready to build (Just need to use adevtool to pull extra bits from stock OS images)
            • Consistent security patches monthly
            • Easily obtainable OTA and factory images for extracting files from
            • More complete patching - Pixels ship a lot more than the baseline mandatory patches in Android Security Bulletins each month

            That's a non-exhaustive list, which to-date, I have not found another device meeting these requirements. Just because a device looks like it supports a feature, for example a user defined root of trust for verified boot, does NOT mean it does it properly - for example, several OnePlus devices do not implement this properly at all. Hell, look at FairPhone, they can't even sign their OS with signing keys which are not the public test AOSP signing keys. Most of the industry is a damn shitshow. Having proper verified boot is a very important part of the Android security model.

          • pipe2null

            What do you consider the top big-picture problems when contemplating bring up a platform?

            Only Pixels have AOSP support, you will have to create device trees and integrate any non-AOSP components from SoC vendors etc yourself. Oh and there's basically scarce to no documentation for most of AOSP.

            Rough idea of typical workflow Graphene devs use while bringing up new supported platforms?

            It's not comparable to what you want to do as Pixels have AOSP support.

            How high is the chance of bricking my physical dev device? Outside of disposable wifi routers, I have not mucked around with brick-able low level bits of embedded OSs, so don't know how reliably anti-brick the process is.

            Once you have things wired up, quite hard, nearing impossible.

            Any rough idea on what types of devices (drivers) are "likely" supported out-of-the-box with stock Graphene, aka at least enough to get a booted and usable state, versus known "likely" problematic devices?

            This isn't really the right question. GrapheneOS relies on AOSP's device support, which is only Pixels.

            Any specific reasons I should not pick up a cheap (but top-end "claimed" spec) android device off aliexpress to use as a personal play/development device and/or potential target platform?

            Nothing aside from Pixels really has the care and effort placed into implementing hardware security features whilst offering full, properly implementing support for an alternate OS. You can't have a reasonably secure OS on a device where the hardware is architecturally insecure and lacking several critical hardware security features.

            TLDR from me: Buy a Pixel.

            • Durov is just spreading panic and misinformation as usual in the linked posted. They are not a reliable source of information, at all. 0days happen in software all the time, Telegram is no exception.

              If an adversary were to compromise an app only (e.g. arbitrary code execution within the application sandbox) then they can access everything the app could. If they then chained exploits together taking advantage of multiple vulnerabilities (For example a kernel bug allowing for escalation of privileges and thus gaining code execution/information outside of the application sandbox) then they could potentially view content which the application sandbox would not permit going all the way up to any content on the device. It's not really a question which can get a boolean response, rather it depends on the circumstances and the goals of the adversary, as well as what vulnerabilities they are leveraging.

              • If it works on the stock OS it works on GrapheneOS.