Hacker News Reader

Comment by faust201 | Hacker News Reader

> Isn't that how a system app proves to the system that it is, in fact, a system app?

No.

In a way it does not matter if the app is system or not. Even user apps (signed with some other key) can be powerful to do damage.

System partitions cannot be edited due to SELinux and also thesedays the partition ext4 is created with certain blocks - cant be changed.

Yes one can use magisk to do some gimmick - but that is kinda telling OS - Allow me to do anything.

The notion of locked bootloader as a holy grail against anything is stupidity. Apps inherently have too much power - assuming user somehow granted permissions. (or you are from a 3-letter organisation - incl. NSO)

View on HN

>In a way it does not matter if the app is system or not. Even user apps (signed with some other key) can be powerful to do damage.

That might be true, but at the same time you shouldn't run random scripts off the internet as root, even though there are plenty of EoP or RCE exploits. The same applies to letting random apps get privileged permissions, even if sophisticated attackers can bypass those permissions with 0days.

>System partitions cannot be edited due to SELinux and also thesedays the partition ext4 is created with certain blocks - cant be changed.

That's irrelevant on Android because system apps can be updated without touching the /system partition, if the .apk is signed with the same key. The system will store the updated .apk file in /data/app, but otherwise grant it privileged permissions that only system apps can get. That's how google play services can update itself and still keep its privileged status, even though the phone OS hasn't been updated in years.

> That's irrelevant on Android because system apps can be updated without touching the /system partition, if the .apk is signed with the same key. The system will store the updated .apk file in /data/app, but otherwise grant it privileged permissions that only system apps can get. That's how google play services can update itself and still keep its privileged status, even though the phone OS hasn't been updated in years.

How is this relevant? Yes, in a custom ROM - USER NEEDS TO BE CAREFUL. (i.e) if someone installs random app - signed by AOSP keys (and that ROM was installed by AOSP keys) it will get installed.

I am yet to see proof that this causes major meltdown.

Reg complete ROM- Except for this: https://wiki.lineageos.org/signing_builds#changing-keys

Assuming a phone was securely installed (after verifying sha/sig) with lineageOS RECOVERY and ROM - it will not accept a build with different sign keys. (i.e) AOSP keys.

>How is this relevant? Yes, in a custom ROM - USER NEEDS TO BE CAREFUL. (i.e) if someone installs random app

It's relevant because it's an exploit vector that can be easily closed with basically zero downside, but for whatever reason it hasn't. Besides the risk of having such holes in the first place, the lack of willingness to fix is indicative of the security culture of the organization as a whole (ie. not very good).

>I am yet to see proof that this causes major meltdown.

It doesn't cause a major meltdown because most people don't use lineageos, so mass infections don't bother targeting them. That doesn't mean the system is actually secure. It's like using netscape navigator to browse the web. It might not cause a "major meltdown", but only because nobody bothers targeting it, not because it's actually secure.

>Assuming a phone was securely installed (after verifying sha/sig) with lineageOS RECOVERY and ROM - it will not accept a build with different sign keys. (i.e) AOSP keys.

Right, but the allegation is that /e/os uses test keys, either intentionally or through incompetence.

> Yes, in a custom ROM

GrapheneOS is an alternative OS, that keeps the same security model as Android. It's not a "custom, hacked thing that disables the security".

> Assuming a phone was securely installed (after verifying sha/sig) with lineageOS RECOVERY and ROM - it will not accept a build with different sign keys. (i.e) AOSP keys.

Do you know which keys are used by Lineage? My understanding is that some phones running Lineage use the testing keys. Simply because some phones don't allow "custom keys". But that means that it defeats the point of the signing.

Are you saying that the signing is useless in Android?

This does not sound very informed, to be honest. I can also throw random words like SELinux and NSO, but that's not bringing anything to the discussion.

Your top question is like...

I have no idea what is security. What is good? Such questions cannot be answered easily. Read https://ssd.eff.org/module/your-security-plan

- Trying to protect all your data from everything all the time is impractical and exhausting. - There is no perfect option for security. Not everyone has the same priorities, concerns, or access to resources. Your risk assessment will allow you to plan the right strategy for you, balancing convenience, cost, and privacy.

- Some install custom ROM because they don't install 3rd party apps like WhatsApp etc but want to use only OpenSource Email - Some may say - using original factory ROM is bad for privacy as Google snoops a lot but they have some assurance that some random script kiddie cannot take over

- Some want security but not privacy (i.e) get a ChromeOS - yes everything is given to Google but Google has one of the best security team in the world.

My question is:

> Doesn't that mean that I could write an app, sign it with those keys (they are public, since they are for testing), and then have it behave like a "system" app on those devices?

Reply on news.ycombinator.com