I don't know if I have to say this, but please do not use postmarketOS on a personal device if you are doing anything security critical or requiring high levels of data protection. Android or iOS are much better options for this. I would generally recommend a Google Pixel with GrapheneOS if you really need peace-of-mind. Heck, a random stock Android ROM from a carrier phone is probably more secure with some adb work.

#PostMarketOS #Android #iOS #CyberSecurity

@justsoup

?????
Why ?

@lienrag Why is pmOS insecure? That would take a really long time to explain, but the basis is a lack of sandboxing, simple root access, hackability over security, and a lack of bootloader locking. I can go more in depth if you would like.

@justsoup I presume you're comparing to an up-to-date Android installation... ?

@iooioio Yes. Old versions of Android really just depend on if they have exposed vulns.

@justsoup why is that? are there critical security features which aren't available in pmos? if so, which would those be?

@justsoup ah, I see I missed some messages from above. About rootability and bootloader unlocking, tbh that sounds like a good thing, not a bad thing. Bootloader locking made it so that, in most implementations, manufacturers have the final say on whether the user is allowed to install another OS than the manufacturer approved one, aka theirs. Preventing root, this only exists for preventing users from digging deep into the system and optimizing it, or replacing certain parts of the system with more privacy-respecting ones, etc. All the above measures exist, for the most part, to make sure the manufacturer has the ultimate control. This can be a security model, but only as long as all you fear is from the outside, and nothing you're trying to do impedes the company's profits. If the bootloader could be relocked by the user with their own keys and made so that the user manually trusts the OS being booted, if we used polkit and PAM more rigorously and same for sandboxing technologies like flatpaks, I think we would be enough of the way there that what remains would be a rounding error

@justsoup How does pmOS compare to jolla/sailfish and the flx1-thing, security wise?

@justsoup I disagree, pmOS is just like a Linux distro on your desktop. You're in charge and decide how it's going to work.

I wouldn't trust *any* iOS or Android phone with my personal data (like conversations with family/friends), but I have no issues doing the same on pmOS because I configured, hardened and containerized it to my liking and I have FDE enabled which stands even against state-level attackers.

Stock Android from $VENDOR is absolutely NOT private or secure. Pre-installed bloatware spies on you, while state-level attackers can pwn you in many ways (either with RCE zero-day malware, or with cellebrite which exploits USB HID quirks).

@justsoup Duranium is secure enough for most people if you still want smth akin to Verified Boot
When it comes to SELinux... we would need a Secureblue port, which is more than enough imo

@elly @justsoup AFAIK GrapheneOS or even AOSP without custom patches is still hundred times more secure than most Linux desktop distros
There's a reason GOS in particular is used by criminals

@stilic @justsoup lol, no

@elly @justsoup @stilic it is worth noting however that there are no integrity checks on boot in pmOS right now.

@elly @justsoup @stilic doesn't mean you can't implement it yourself though

@fun @justsoup @stilic Absolutely, you can provision your own keys and re-lock the bootloader if you want to (on Google Pixels and Nothing's phones). With U-Boot as a bootloader it would be really simple as well (build, sign, flash, re-lock, OS booted via EFI won't need re-signing on kernel updates).

I also want to (eventually) introduce USB authentication and SELinux to help with runtime exploit mitigation

@stilic @elly @justsoup The fact that criminals use [X] doesn't imply that [X] is secure. Just take a glance at how most criminals (especially in Eastern Europe) just use plain old Telegram. Or the famous EncroChat fiasco.

As for whether GOS is more secure than most pmOS - well, it's hard to give a binary answer here. GOS has some really neat exploit protections (e.g. their implementation of USBGuard, hardened_malloc, etc), but at the same time they don't care about properly isolating cross-app communication and preventing data harvesting from some particularly invasive apps.

If you want to, pmOS can be far more secure than GOS can ever be (unless they move away from Android altogether I guess), but that nonetheless requires some tinkering.

@elly @fun @justsoup @stilic I think the point of aster's post is that pmOS currently doesn't implement this stuff by default, so if you don't know what you're doing then you shouldn't rely on it.

@stilic @elly @justsoup Not to even mention the most important factor here - maintainers. If the whole development and decision model is centered around a single person who can't take criticism without lashing out on social media, I'd be very wary of treating such software as "trusted". Judging solely by this aspect, pmOS (and Alpine Linux) devs are far more trusted than GOS :p

But that's just a cherry on top of this whole discussion. The technical merits are important, but ultimately you *have* to trust to maintainers of your computing base.

@weirdtreething @fun @elly @stilic That's exactly the point. If you implement all of this on your own, you've deviated from stock to the point that the system is nearly unmaintainable, and then you have that issue on your hands. It is not that pmOS could *not* become something very secure, but that currently it is not and people seem to think it is for some reason.

@justsoup @weirdtreething @fun @elly @stilic
also LMAO at Tails's FAQ (pretty much) claiming that their OS will never work on phones: even though their security model largely boils down to simple acts like apparmor, randomized MAC adresses and not saving system logs or browser history to disk.

@moses_izumi @fun @weirdtreething @justsoup @stilic MAC address randomization on wireless interfaces is a default setting in NetworkManager these days AFAIK, it drove me nuts at one point (because my home WiFi has WPA3-only and strict ACL)

@elly @moses_izumi @fun @justsoup @stilic it breaks my static dhcp configs :(

@elly @justsoup security is not a monolith, it's complicated.

pmOS is currently infinitely more secure against rando drive-by shit and "install this totally legit app" scams simply due to obscurity, no criminal who's in it for the money would target it right now. Also pmOS can do usbguard (unlike vendor android) and even without usbguard there's the fact you're running a fresh kernel with all known bugs fixed in usb peripheral drivers. (And you can just not have usb host working LMAO)

At the same time it does indeed prioritize hackability over security. (This will be less true for a fully-baked Duranium eventually!) Meanwhile there is a loooot of stuff designed to protect against various advanced threats that's available in Graphene and iOS w/ Lockdown. And frankly "I enabled old school desktop FDE that cannot evict the key from memory while the system is running at all" does not compare. (Better storage encryption is being worked on, but it's not there yet.)

@valpackett @elly @justsoup Android doesn't keep keys in memory? How is it able to decrypt stuff then?

@esoteric_programmer @justsoup the problem is pmos doesn't support the custom key bootloader locking that android supports, ie no user secure boot keys, ie no secure boot chain, ie a lot of shit down the chain can be comprimised without end user knowing

@weirdtreething @elly @justsoup read this for an overview of the scheme; basically Credential Encrypted keys only need to be decrypted while the session is unlocked, and can be evicted otherwise (e.g. if enough of idle time passes), and decrypted again on unlock using the password.

@nullenvk @elly @justsoup I'm not really sure you understand the difference between security and privacy
I'm not an expert in this field but... y'know? https://privsec.dev/posts/linux/linux-insecurities/

@nullenvk @elly @justsoup Also GOS provides sandboxed GMS for example, which does improve privacy quite a bit because they don't give it much more access than your average Android
One of the goals *is* to provide both better security *and* privacy

@elly @justsoup @nullenvk About the "properly isolating cross-app communication" part: they do have improved the users / work mode infra to allow for better isolation
https://grapheneos.org/features#improved-user-profiles

@elly @justsoup @nullenvk it technically goes along "preventing data harvesting from some particularly invasive apps" but that depends on set it up
GOS makes sure their default experience is reasonably private, so I don't think they're to be blamed for this
https://grapheneos.org/features#privacy-by-default

@justsoup @weirdtreething @elly @stilic it isn't necessarily unmaintainable?

@weirdtreething @elly @moses_izumi @justsoup @stilic Yeah I think Aster meant people just installing stock pmOS as-is with no changes anywhere and thinking they're completely secure. Of course if you're concerned and/or know what you're doing, you can harden it yourself somewhat easily. But also, no security is much better than a false sense of security.

@weirdtreething @elly @justsoup @moses_izumi @stilic A lot of it depends on your threat model though. If you want *good* security for your usecase, you need to understand your threat model. It is useless to harden everywhere if you don't even know what you're protecting from.

@elly @justsoup @moses_izumi @stilic @weirdtreething also see: OpenBSD (lots of hardening, lots of mitigations, but for what?)

@justsoup @weirdtreething @fun @elly @stilic
The security thing kinda comes down to postmarketOS prioritizing hardware support above all else: for better or worse.

If I were a maintainer I might be more concerned about:
- packaging more applications for APK, instead of falling back on the Flatpak ecosystem
[shipping gobs of libraries doesn't make sense on phones, especially if there's no microSD slot]

- pairing KDE Plasma with a more lightweight window manager and/or compositor
[Wayland backend runs like crap on my Intel HD 4000 and UHD 620 laptops]
[X11 backend is fine, but XFCE is still faster]
[Discover takes an annoying amount of time to load on my i5-3320M]

- shipping images with a non-UEFI bootloader
- providing a dedicated pmbootstrap liveCD
[as a recovery thing]

- making a Wine frontend, just to have one last laugh at the Windows RT and Mobile situations

I'd basically be treating it as an Alpine equivalent of the various lightweight desktop-oriented Debian offshoots (Antix, MX Linux, Q4OS, early Ubuntu).

To be frank I haven't tried pmOS on a phone/tablet, only my i5-8350u laptop.
(didn't even use pmbootstrap, just flashed the AMD64 disk images)

@moses_izumi @elly @weirdtreething @justsoup @stilic

> The security thing kinda comes down to postmarketOS prioritizing hardware support above all else: for better or worse.

What do you mean by that? Hardware may be our priority but it isn't the *only* priority.

> - packaging more applications for APK, instead of falling back on the Flatpak ecosystem
> [shipping gobs of libraries doesn't make sense on phones, especially if there's no microSD slot]

apk is the main way of getting apps installed in postmarketOS. Many postmarketOS maintainers also maintain a few packages in Alpine aports and some of them are even Alpine developers. Things like the GNOME and KDE stacks have some postmarketOS folks involved. KDE was originally packaged by a postmarketOS developer.

If you feel there's a lack of apps in apk, then the Alpine folks certainly wouldn't mind more people getting involved packaging :)

Unless you're talking about the immutable version, Duranium, which does currently prioritize Flatpak, however it is still in its very early days and much more WIP than "classic" postmarketOS.

> - pairing KDE Plasma with a more lightweight window manager and/or compositor
> [Wayland backend runs like crap on my Intel HD 4000 and UHD 620 laptops]
> [X11 backend is fine, but XFCE is still faster]
> [Discover takes an annoying amount of time to load on my i5-3320M]

We won't alter desktop environments beyond what is officially supported upstream. These are things you can do yourself. You can even use different desktop environments like XFCE4, LXQt, MATE, sway, and plenty more :)

That being said, Plasma Mobile runs quite well on my ancient tablet, which only has 4x Cortex-A9 + Mali400, and that is Wayland-only. I've heard lots of progress towards making KDE more lightweight, and I've been told it can even run on ancient 20 year-old hardware mostly fine.

> - shipping images with a non-UEFI bootloader

80% of device ports ship images without UEFI support, so I'm also not sure what you're talking about, unless maybe you mean the generic-x86_64 device port.

No one has added BIOS to that port yet, you're welcome to step in and do it. But I will say that I'm writing this from a 2011-era laptop booted to postmarketOS over UEFI, so UEFI is not *that* new either (I even have a 2006 MacBook which also supports EFI)

> - providing a dedicated pmbootstrap liveCD
> [as a recovery thing]

There's os-installer for that I think, would that be enough for you? A bunch of other prebuilt x86_64 images are available too which can be used for recovery, though changes are persistent (maybe we could support nonpersistent livecd).

> - making a Wine frontend, just to have one last laugh at the Windows RT and Mobile situations

apk add wine and have some fun ;)

@moses_izumi @fun @elly @weirdtreething @justsoup @stilic

[Wayland backend runs like crap on my Intel HD 4000 and UHD 620 laptops]

That hasn’t been my experience at all. I use it on laptops with HD4600 and UHD620 and it’s fine.

@noisytoot @moses_izumi @elly @justsoup @stilic @weirdtreething Latest GNOME with wayland runs completely fine on HD4000 (while being quite slow on GNOME+X11) so I'm not sure how KDE wayland would run this badly

@noisytoot @fun @elly @weirdtreething @justsoup @stilic
On the UHD 620 machine, KDE for Wayland runs worse than it should (both on Debian and pmOS).
Haven't tried pmOS on the HD4000 machine because it's been flashed with SeaBIOS (prepacked pmOS images default to systemd's own bootloader, which only supports UEFI).

@moses_izumi @noisytoot @elly @weirdtreething @justsoup @stilic It could also very well be broken GPU drivers or something

@moses_izumi @elly @justsoup @noisytoot @stilic @weirdtreething (compositor requires at least GLES2 iirc, else it does sw rendering and yes that'll be slow)

@fun @elly @weirdtreething @justsoup @stilic
yeah I'm talking about the generic x86-64 images.

@fun @elly @weirdtreething @stilic Unmaintainable in the context that pmOS updates wouldn't apply cleanly or could break the setup, so it might as well just be Alpine.

@robot @justsoup ah ok, that changes things slightly indeed, but even so, a lot of the post above stands because many of those features were originally intended, and are still used for, manufacturers continuing to extract rent from the user long after they paid for their device in full, which is as far from user empowerment as one could get