Privileged Extension should not allow circumventing "Device Administration App"

Since 2.2, there is a Device Administration API that lets trusted admins setup an app to do things like remote wipe, set group-wide password policies, etc. The Privileged Extension should not circumvent this app when its set up as "device owner", but it should be able to install and update those apps. Here's the discussion on #copperhead:

hc: we should chat sometime about how you're including apps into the ROM. It seems that some apps are being built as part of the ROM. That means that F-Droid can't update them.

strcat: anything bundled in the ROM is intentionally going to be signed with our keys, but there's no choice for F-Droid if it needs platform privs

strcat: it's a similar problem to enabling both guardian project repo and standard f-droid repo

strcat: you can't update from one to the other, users might not understand

hc: yup, we're working on merging those, so that both repos provide the exact same APKs via reproducible builds

strcat: I don't want to bundle apps as a general rule but F-Droid needs to be bundled, and for Silence it's replacing a stock apk

strcat: needs to be a bundled SMS client and I removed Messenger

hc: why do you want to build the apps from source when they are bundled? That means you can only update them by flashing the ROM, which requires a reboot

strcat: it doesn't require that, it only requires that they're signed with same releasekey

hc: well, really, its not building that's the issue, its the signing key

strcat: we could push updates via an F-Droid repo if we really wanted

strcat: if anything is bundled I want to have the key

hc: that means you are then responsible for all updates to those apps

strcat: yes

hc: seems like a lot of maintenance work to add to your load

strcat: there are not going to be more bundled apps

strcat: it's a tiny amount of work

hc: well, you're not yet providing timely updates to those apps, i.e. something fdroid can install

strcat: chromium is updated multiple times a month, it takes hours to build and I need 4 variants (WebView 32-bit, WebView 32-bit + 64-bit, Chromium 32-bit, Chromium 64-bit)

hc: on a daily basis

hc: its updated via the ROM update?

strcat: everything is, I don't do out-of-band updates right now

strcat: we could but it's pointless

hc: people are going to get sick of reboots and ignore the updates

strcat: they have bigger problems then

hc: well, apps can better be updated via Fdroid

hc: on an hourly basis is totally feasible

strcat: they still need to be updated in the base OS too if they're bundled, but could ship earlier via F-Droid

hc: sure, update them in the base OS whenever the base OS needs an update

strcat: and for the new generation devices they are introducing chromeos-style updates

strcat: which will be unattended updates

strcat: it does it for you and tells you when it's ready to reboot

hc: yeah, still requires a reboot

strcat: but our fork of the CM updater won't know how to deal with that right away

strcat: can be fixed tho

hc: isn't there the /vendor/app location or something like that for shipping other people's binaries?

hc: the problem is really different signing keys, it makes things hard to manage and can easily end up confusing users in a way that looks like malware

hc: we don't want people seeing "the signing key is different" messages

hc: really as rarely as possible

strcat: it shouldn't try to update it if there's a different key

strcat: there are a hundred apps in the OS itself

hc: yup, we're working on that

strcat: there are 2 that are also on F-Droid

hc: but its not that simple

strcat: although F-Droid also has some old AOSP apps but they are really old so doesn't prompt about updates

hc: yeah, I'm talking about apps like Silence and F-Droid itself

hc: I'm not saying move apps out of AOSP into F-Droid

strcat: F-Droid has platform signature privs (either itself or privileged extension which grants to main app) so it shouldn't be using a different key than the OS

strcat: it can't really since part of it needs platform key

hc: we're rearchitecting the F-Droid Privileged Extension around that

hc: the idea is so that it is designed to be built into ROMs and signed by the ROM key

strcat: the privileged extension trusts f-droid though

hc: so instead of relying on signature perms

strcat: it's breaking the security model if f-droid isn't considered part of the OS too

hc: priv-ext checks the sender of install/uninstall requests against a built-in whitelist of packageName+signingKey

hc: priv-ext is then built-in and signed by the ROM

strcat: I don't want to expose ability to do unattended installs, etc. to a non-ROM key

hc: F-Droid.apk can be installed anywhere, and as long as it is signed by a key in the whitelist, priv-ext will accept commands from it

hc: why does the ROM signing key matter here?

hc: it'd be the same code that does the installs no matter which signing key

strcat: except it can update itself then, with a key we don't control

hc: not in this design

hc: priv-ext has a separate packageName and signing key so no signature perms

strcat: F-Droid is trusted by it though

strcat: and F-Droid can then update itself

strcat: so platform privs are exposed to another trusted party

hc: only install and uninstall are exposed

strcat: yes, unattended install/uninstall of anything

strcat: which could include removing a device manager, etc.

hc: except where there are signing key conflicts

hc: we're not talking removing system apps

hc: only /data/app apps

strcat: I know

strcat: a device manager wouldn't be a system app

hc: what's a device manager in Android?

strcat: mobile device management stuff

hc: why not put that into the ROM?

strcat: typically for when user is not the owner

strcat: it doesn't belong in CopperheadOS itself

strcat: and ppl would want different ones

hc: what if we added a packageName blacklist to the priv-ext?

strcat: that might help but I'm still going to want to build/sign any code that's bundled, especially if it has even just a few platform privs exposed to it

strcat: I similarly don't just use google's WebView apks

hc: sure, the priv-ext is designed to be built and signed as part of the ROM

hc: by the way, the current design is already drastically constrained as compared to Play Services and Play Store

hc: so the use case you're talking about here is were basically the IT dept sets up devices, installs some device manager software on it, and they want it so that the user cannot remove that device manager?

hc: can't the user just uninstall it in Settings->Apps?

strcat: no

strcat: it owns the device

strcat: it can wall off developer settings, etc.

strcat: and you need dev settings to enable oem unlocking

strcat: you can't unlock bootloader without that

strcat: etc

hc: so the priv-ext could just ignore apps that own the device

hc: no installs or uninstalls

hc: do you know off hand of a good resource on that stuff so I can read up on the details?

strcat: it would be helpful if it had some sort of device manager api integration

strcat: play store probably has that

strcat: https://developer.android.com/guide/topics/admin/device-admin.html

strcat: https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html

strcat: isDeviceOwnerApp

strcat: Added in API level 18

strcat: boolean isDeviceOwnerApp (String packageName)

strcat: Used to determine if a particular package has been registered as a Device Owner app. A device owner app is a special device admin that cannot be deactivated by the user, once activated as a device admin. It also cannot be uninstalled. To check whether a particular package is currently registered as the device owner app, pass in the package name from getPackageName() to this method.

strcat: not sure if f-droid can uninstall it atm or if package manager will refuse

strcat: possible OS already takes care of it

hc: priv-app uses the same API as Play I think

hc: the PackageManager normal API I'm sure covers that

hc: mind if I post this thread on a public fdroid issue?

strcat: don't mind

strcat: I don't know if f-droid has to do anything

strcat: haven't played with any of this stuff yet but we'll need it to deal with business deployments

strcat: and I want to use the same CopperheadOS, just with a device manager app installed

strcat: and we could add an F-Droid repo for it and it takes care of updating it

hc: I think it shouldn't be too hard to make the priv-app work for that use case

hc: so how do you know when you want F-Droid to be able to update/install/uninstall the device manager app, and when it should be prevented from doing it?

strcat: it should always be able to update them (the key just has to match and it shouldn't be able to downgrade)

hc: so only uninstall restrictions are needed for the Device Admin APp

strcat: and only if it doesn't already take care of this, I don't know

strcat: high chance it does

strcat: but for the normal api

strcat: if f-droid's priv-app stuff is doing something else, that might bypass it

hc: does Google Play let you install/uninstall/update these apps?

strcat: it doesn't let you uninstall it if you're not supposed to be able to

strcat: so once it's registered as a device manager

hc: the priv-app is using the same API as Google Play, as far as we know

hc: so to recap:

hc: * F-Droid Privileged Extension is built into ROMs as a priv-app and signed by the ROM key

hc: * F-Droid gets no special perms

strcat: the priv extension treats f-droid in a special way though

hc: * F-Droid signed by f-droid.org key gets only uninstall/install access via the priv app, and cannot uninstall Device Manager Apps

strcat: so it does get special perms via that

hc: I mean no Android-granted perms

hc: no priv-app, system, etc.

hc: signature

strcat: ah

hc: does that sound workable to you?

strcat: I'm still wary of bundling stuff not signed with OS key

hc: most commercial ROMs do, e.g. Play Services

strcat: it's not trying to be like those

hc: can you think of any other specific issues?

hc: sure, but at least security-wise, its not a bad idea. Samsung has to bundle Play Services, and they hate Google ;-)

strcat: it's a security problem imo

strcat: and more restrictions and checks are needed for /data to make verified boot useful beyond 'malware cannot persist past factory reset'

hc: because someone can get the fdroid signing key?

strcat: yes it's an extra trusted key

strcat: OS ones have to be trusted but that one doesn't need to be

hc: we're going to have the signing procedure pen-tested, its fully offline

strcat: if we're bundling something I consider us responsible for it, if we can be

hc: sure, but its not like you can read the entire F-Droid source code each time

strcat: as long as it's simply Nexus hardware there are other trusted parties but I want to minimize it

hc: that makes sense, but you're already trusting the code, and we're building in as much automated audited as possible

hc: plus updating over tor means no targeted software delivery via fdroid

hc: so if someone steals the fdroid signing key, they need to phsysically get the device, and if someone can get the fdroid signing key, they can break into the device when its in their hands

hc: the upside of trusting the fdroid signing key here is that the updates come automatically and rapidly, without a reboot

hc: or without you building it or even thinking about it

strcat: f-droid is such a small problem compared to other stuff we have to deal with tho

strcat: like chromium where it takes a day to deal with it

hc: that reminds me, one of the things that we're going to build is "curation tools" for building custom fdroid repos from other trusted repos

strcat: we used to just bundle the f-droid apks for f-droid and smssecure

strcat: and a few other apps which are no longer bundled