Skip Navigation

Posts
18
Comments
890
Joined
2 yr. ago

  • Related to relockable bootloaders and the security they provide, I was under the impression that if a malicious bit of software were to make use of some privilege escalating vulnerability and modify the kernel, the phone would fail to run in some way (ignore the rest of this if that isn't the case). I dont think security should be dependent on the user behavior in basically any case.

    For example, a FOSS developer in our communities could suddenly lose it and modify an existing app of theirs to inject malicious code making use of a vulnerability in android and we'd have know what of knowing until the damage is reported. Good user behavior is very important for security, but we can't all be auditing our apps for each new release, even though its quite unlikely to happen.

  • now my fucking arm is dislocated. thanks 196 lemmy 🙄😒🤕

  • I didnt think that my balls would just detach like crayfish arms. fucked up.

  • It still has much of the google proprietary blobs still included and relies on google services, also without significant effort to harden Android. I have also heard that sometimes they fall behind on updates to their apps by weeks at a time (correct me if I'm wrong I am still looking for the source I found this info from). It may be moderately degoogled, but their security just ain't there. In some cases (like OEM EOSL for older devices) having a 3rd party ROM may improve security with more up to date patches. Unless the bootloader is relockable and secure boot is possible, you will be compromising your device's security (and privacy along with it) and destroying the Android security model in general.

  • I'm out here living my comfy carpenter bee life eating wood and other shit

  • fuck u, that hurt. I shouldn't have listened to you

  • MASS IVECO CK

  • There is no android ROM that is fully degoogled without losing out on much of base Android's functionality. See the table I link under the other person's comment. I have also heard that /e/ OS falls behind on package updates from its forks of other projects, many of its default apps.

  • /e/ is not very degoogled. DivestOS or GrapheneOS would be better choices, then maybe CalyxOS.

  • Yeah, any security focused android ROM won't include root because it breaks the android security model. Breaks the ability to have secureboot and system safety checks by apps.

    1. My point was that standard linux should have those things too if it wants to be considered "secure". Default Linux isn't secure out of the box without a lot of work. It is more private than proprietary OSes but not more secure, therefore compromising your ability to safeguard privacy as a result. Linux is also a great target for threat actors because the majority of servers run Linux, meaning security researchers and cyber criminals alike are looking for weaknesses. I'd recommend looking into Android's Security model because it is interesting and gives insight on designing a secure mobile device. Stock Android suffers from OEMs not providing consistent long-term updates for devices, which 3rd party security hardened ROMs like DivestOS and GrapheneOS help to address.

    Extra reading: see Whonix comparison table to see what they look for when choosing a base OS that can be later hardened for security. Note that some things in the table are not security specific but important for anonymity (which Whonix modifies to Kicksecure to better protect). Whonix is a security focused operating. Here is a comparison of different memory allocators showing their features for preventing different types of exploitation. Memory based attacks consistently are reported to be one of the most common types of attacks.

    1. Here is a link to the Wikipedia page on Linux-libre Kernel. I'm not suggesting this should be the default, was just making a point that binary blobs may be needed in a kernel for compatiblity or security (eg updating firmware that is vulnerable when that happens).
  • Point still stands. postmarketOS isn't hardenned. Default desktop linux isn't hardened. Malware could easily infect your device and exfiltrate data, escalate privileges, modify the kernel, etc. Each of the things I have mentioned (hardened_malloc, immutable OS, hardened kernel, hardened firewall, removal of identifiers, full disk encryption, locking of root login [not the same as invoking root], MAC hardening through SELinux or/and AppArmor, service minimization for reduced attack surface, package manager hardening, secure boot, sandboxing of applications, etc) should be implemented for both Desktop or Mobile Linux to have "good" security. Security is preventative. All of these things come together to create a system better equipped to protect against know and unknown threats, which especially true for mobile devices which are near-costantly in unknown environments. A vulnerable device is weak link in the chain of your security, which can be used to compromise your privacy. You may never be attacked or have your device exploited, but that doesn't make it secure as a result.

    I would love to see an actually secure mobile device that is rid of Google's stench. Problem is postmarketOS isn't secure, its just default linux on a phone. If it saw largescale adoption (which we all would like a good alternative to do) it would be easily exploited.

    It says postmarketOS is based based on alpine Linux, which according to Whonix doesn't meet their threat model and it's odd to claim "Alpine Linux was designed with security in mind" when Alpine's package doesn't pass The Update Framework model. A vulnerable package manager can be used to compromise a system, read more package management on TUF's website.

  • Did you go to any of my links about Linux hardening? Do you implement any hardening yourself? Do you harden kernel flags or replace malloc with hardenned_malloc?

    If PostmarketOS is just ARM linux with minimal changes than it isn't secure enough for a mobile device. All apps should be sandboxes regardless of whether you can trust the code or developer. Each app expands the attack surface of your device.

    Linux kernel also has proprietary blobs for firmware and device support. That is the difference between Linux normal or libre kernels.

  • Nah I dont think that at all. But DivestOS and GrapheneOS are the most security hardened. DivestOS takes extra steps to further deblob Android of proprietary bits to further reduce attack surface. See my other reply for my detailed (barely scratching the surface) insight into why Linux isn't a good mobile OS, but more so how Linux isn't security hardened well at all by default.

  • Security through obscurity is not security. There are special considerations that have to be taken on a mobile device. Mobile OSes, while unhardened normally, are still designed to protect against attack vectors that aren't considered by normal linux. Linux can be hardened, but is very open by default. It also offers no default sandboxing of apps from each other. It isn't immutable, unless postmarketOS is, which is a large security threat when considering device integrity. Full disk encryption isn't enabled by default (unless changed in postmarketOS). Root login is enabled by default (a huge attack vector). Linux isn't secure by default, but more private than any proprietary OS like Windows, iOS/MacOS, ChromeOS, and Android. But Linux because of its open default makes it vulnerable to spying 3rd party by apps installed by the user. It is also vulnerable to attacks from a network.

    I recommend a deblobbed Android ROM like DivestOS (my personal fav and more deblobbed of proprietary blobs than any other ROM) or GrapheneOS. See a good comparison between ROMs here: https://eylenburg.github.io/android_comparison.htm

    For linux hardening, check out Kicksecure for Debian distromorphing, Secureblue for Fedora Atomic (immutable) rebasing, and Brace by DevistOS's developer for general security hardening of Fedora/RHEL, Debian/Ubuntu, Arch Linux, and OpenSUSE Tumbleweed.

  • Linux mobile is not threat modeled for a moble device. It is quite risky. Mobile devices must consider more known and unknown attack vectors than a device (like a Desktop) that stays in a consistent trusted environment (like home or a personal office in some cases).