Closed thestinger closed 1 month ago
I think that's a fair way to rename it, as "standard app sandbox" is something the casual reader might understand and it's more concise than the current wording.
The signature spoofing is already mentioned in another row just below so I think there's no need to mention it again, especially when the first row is renamed to "standard app sandbox" with no mention of the word privilege. In my understanding, the signature spoofing only has the function to allow apps that want to talk to Play Services to talk to microG instead, but at least on DivestOS microG is still contained in the standard sandbox.
@eylenburg
The signature spoofing is already mentioned in another row just below so I think there's no need to mention it again, especially when the first row is renamed to "standard app sandbox" with no mention of the word privilege. In my understanding, the signature spoofing only has the function to allow apps that want to talk to Play Services to talk to microG instead, but at least on DivestOS microG is still contained in the standard sandbox.
It allows them to pretend to be Play services instead of failing the signature check due to having the wrong signing key.
It would be a good idea to rename this row to use a clearer name. GrapheneOS and DivestOS can simply be
Yes
without extra details and the others using microG would still beNo
but more details can be provided in the title text explaining that they run it in thepriv_app
SELinux domain instead ofuntrusted_app
, which gives it access to internal system APIs and data along with it being much less isolated. The difference betweenpriv_app
anduntrusted_app
is MAC policy, but the MLS policy is also different becausepriv_app
gets placed into a per-profile MLS level vs. a per-app-per-profile level for untrusted_app. This means one untrusted_app can't do any low level interactions or data sharing with another app, but a priv_app can do that with another priv_app or other components. They also give privileged permissions to microG.DivestOS avoids doing either of those things, but DivestOS still gives it privileged access in the form of signature spoofing. Therefore, the current row is a bit misleading because it says DivestOS has it unprivileged but that's only mostly true. Being able to pretend to be a specific app is still a special privilege, and relevant to privacy/security, such as how microG doesn't secure connections to the services as much. I don't really think this needs to be covered.