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