F-Droid privileged extension

[thestinger]

No description provided.

[oatberry]

What's preventing this from working?

[oatberry]

What's preventing this from working?

[alxxlc]

No root access when installing the extension. At least, that's the issue I had.

[alxxlc]

No root access when installing the extension. At least, that's the issue I had.

[thestinger]

This issue is about bundling it. Nothing is preventing it from working, it's work that has to be done. Modifying the OS partitions can never be supported and isn't what I filed the issue about.

[thestinger]

This issue is about bundling it. Nothing is preventing it from working, it's work that has to be done. Modifying the OS partitions can never be supported and isn't what I filed the issue about.

[anantshri]

I can install packages on nexus 5x from f-droid directly without changing any permissions. So is this implemented or are we still waiting on it.

[anantshri]

I can install packages on nexus 5x from f-droid directly without changing any permissions. So is this implemented or are we still waiting on it.

[thestinger]

It's not implemented. I don't think it would provide any functionality yet but it's going to need to be done.

[thestinger]

It's not implemented. I don't think it would provide any functionality yet but it's going to need to be done.

[eighthave]

This is now implemented, you can build the F-Droid Privileged Extension using the Android.mk that has been merged in: https://gitlab.com/fdroid/privileged-extension/merge_requests/3

@relan built it into his ROM, he also wrote that merge request.

[eighthave]

This is now implemented, you can build the F-Droid Privileged Extension using the Android.mk that has been merged in: https://gitlab.com/fdroid/privileged-extension/merge_requests/3

@relan built it into his ROM, he also wrote that merge request.

[relan]

I'd like to work on this. But before I start, some questions:

1. Will Copperhead maintain own mirror of the Privileged Extension repo or manifest should reference https://gitlab.com/fdroid/privileged-extension.git directly?
2. What should happen to the F-Droid package that is already included into CopperheadOS? Will you continue to ship it after the Privileged Extension is included, switch to a prebuilt (by F-Droid) version, or completely remove it?
3. Upgrade path for existing users. Depending on the answer to the previous question, we should figure out how to make OS upgrade (to a version that includes Privileged Extension) seamless.

[relan]

I'd like to work on this. But before I start, some questions:

1. Will Copperhead maintain own mirror of the Privileged Extension repo or manifest should reference https://gitlab.com/fdroid/privileged-extension.git directly?
2. What should happen to the F-Droid package that is already included into CopperheadOS? Will you continue to ship it after the Privileged Extension is included, switch to a prebuilt (by F-Droid) version, or completely remove it?
3. Upgrade path for existing users. Depending on the answer to the previous question, we should figure out how to make OS upgrade (to a version that includes Privileged Extension) seamless.

[thestinger]

Will Copperhead maintain own mirror of the Privileged Extension repo or manifest should reference https://gitlab.com/fdroid/privileged-extension.git directly?

Using it directly would be reasonable but it would have to reference a specific revision or tag in the manifest. It probably makes more sense to fork it right now since it's likely we will end up needing to at least temporarily make some changes now and then. It would also add a third code hosting site as a failure point to the manifest. I would rather not do that. I already dislike GitHub for hosting the code and would like to move it to git.copperhead.co at some point in the future when we have more resources.

What should happen to the F-Droid package that is already included into CopperheadOS? Will you continue to ship it after the Privileged Extension is included, switch to a prebuilt (by F-Droid) version, or completely remove it?

It will still be shipped by default if the privileged extension is included, and it won't be possible to use the F-Droid version due to security features that are in the process of being implemented. Android has nothing comparable to verified boot for apps outside of /system and /vendor and no unverified code is going to be used in the base system. It won't be permitted to update a base system app out-of-band.

[thestinger]

Will Copperhead maintain own mirror of the Privileged Extension repo or manifest should reference https://gitlab.com/fdroid/privileged-extension.git directly?

Using it directly would be reasonable but it would have to reference a specific revision or tag in the manifest. It probably makes more sense to fork it right now since it's likely we will end up needing to at least temporarily make some changes now and then. It would also add a third code hosting site as a failure point to the manifest. I would rather not do that. I already dislike GitHub for hosting the code and would like to move it to git.copperhead.co at some point in the future when we have more resources.

What should happen to the F-Droid package that is already included into CopperheadOS? Will you continue to ship it after the Privileged Extension is included, switch to a prebuilt (by F-Droid) version, or completely remove it?

It will still be shipped by default if the privileged extension is included, and it won't be possible to use the F-Droid version due to security features that are in the process of being implemented. Android has nothing comparable to verified boot for apps outside of /system and /vendor and no unverified code is going to be used in the base system. It won't be permitted to update a base system app out-of-band.

[relan]

So, the point of this issue is applying the principle of least privilege to F-Droid? That is

1. Fork Privileged Extension.
2. Modify it to trust only Copperhead-signed F-Droid client package.
3. Make F-Droid client package non-privileged (revert CopperheadOS/fdroidclient@4a9a01e).

[relan]

So, the point of this issue is applying the principle of least privilege to F-Droid? That is

1. Fork Privileged Extension.
2. Modify it to trust only Copperhead-signed F-Droid client package.
3. Make F-Droid client package non-privileged (revert CopperheadOS/fdroidclient@4a9a01e).

[thestinger]

To some extent, but the privileged extension is also how unattended app upgrades will be implemented which is important.

[thestinger]

To some extent, but the privileged extension is also how unattended app upgrades will be implemented which is important.

[thestinger]

Android 7.0 will also bring unattended upgrade support for the base system for new devices using the new partition layout style, but that will need to be implemented in the Updater app.

[thestinger]

Android 7.0 will also bring unattended upgrade support for the base system for new devices using the new partition layout style, but that will need to be implemented in the Updater app.

[eighthave]

I agree its important to limit privileges as much as possible, but that is not the only factor we need to consider here. Timely updates and frequent auditing are also essential. Therefore, there are a lot of reasons why Copperhead should use the official F-Droid.apk binaries along side the ROM-signed Privileged Extension.

At least until you have a Copperhead repo setup for updates, I think it is important to use the f-droid.org version of F-Droid so that people can get updates as soon as possible. Also, it is important to minimize the amount of updates that are pushed through the ROM update channel because those require reboots and a lot more user interaction. With the Privileged Extension, there can be fully automatic background updates.

Also consider the app swapping functionality: since F-Droid can send an APK directly from one device to another, if a Copperhead user sends F-Droid to a non-Copperhead user, then that non-Copperhead user will not have an update channel for F-Droid since no repository distributes the Copperhead-signed F-Droid.apk.

A more productive way to ensure that Copperhead is not getting malware versions of F-Droid is for Copperhead to run an F-Droid Verification Server that automatically reproducibly rebuilds the F-Droid source and compares to what is hosted on f-droid.org. This could also optionally include an instance of the automated drozer testing that Copperhead has made for F-Droid.

[eighthave]

I agree its important to limit privileges as much as possible, but that is not the only factor we need to consider here. Timely updates and frequent auditing are also essential. Therefore, there are a lot of reasons why Copperhead should use the official F-Droid.apk binaries along side the ROM-signed Privileged Extension.

At least until you have a Copperhead repo setup for updates, I think it is important to use the f-droid.org version of F-Droid so that people can get updates as soon as possible. Also, it is important to minimize the amount of updates that are pushed through the ROM update channel because those require reboots and a lot more user interaction. With the Privileged Extension, there can be fully automatic background updates.

Also consider the app swapping functionality: since F-Droid can send an APK directly from one device to another, if a Copperhead user sends F-Droid to a non-Copperhead user, then that non-Copperhead user will not have an update channel for F-Droid since no repository distributes the Copperhead-signed F-Droid.apk.

A more productive way to ensure that Copperhead is not getting malware versions of F-Droid is for Copperhead to run an F-Droid Verification Server that automatically reproducibly rebuilds the F-Droid source and compares to what is hosted on f-droid.org. This could also optionally include an instance of the automated drozer testing that Copperhead has made for F-Droid.

[eighthave]

I forgot to add: as long as the f-droid.org-signed FDroid.apk is included in /system/app, then the F-Droid app itself will not get any extra privileges beyond the regular permissions it asks for. Only the F-Droid Privileged Extension needs to run with elevated permissions, and that grants install/delete access to F-Droid.

[eighthave]

I forgot to add: as long as the f-droid.org-signed FDroid.apk is included in /system/app, then the F-Droid app itself will not get any extra privileges beyond the regular permissions it asks for. Only the F-Droid Privileged Extension needs to run with elevated permissions, and that grants install/delete access to F-Droid.

[eighthave]

Also, for custom/whitelabel builds that aren't just defaulting to the f-droid.org repo, then it makes perfect sense to use the platform signing key. If it is F-Droid itself being included, that's the case where it should use a reproducible build and the f-droid.org signature.

[eighthave]

Also, for custom/whitelabel builds that aren't just defaulting to the f-droid.org repo, then it makes perfect sense to use the platform signing key. If it is F-Droid itself being included, that's the case where it should use a reproducible build and the f-droid.org signature.

[relan]

If Copperhead isn't going to make any modifications to F-Droid client, I believe it's better to ship F-Droid-signed version via reproducible process.

This will be a much better UX because users want to upgrade apps when new versions are available (even when version bump gives nothing to them).

How about giving users an option to sideload and use official F-Droid client instead of Copperhead-signed one? This will require changing Copperhead's F-Droid package ID and whitelisting two certificates in the Privileged Extension.

[relan]

If Copperhead isn't going to make any modifications to F-Droid client, I believe it's better to ship F-Droid-signed version via reproducible process.

This will be a much better UX because users want to upgrade apps when new versions are available (even when version bump gives nothing to them).

How about giving users an option to sideload and use official F-Droid client instead of Copperhead-signed one? This will require changing Copperhead's F-Droid package ID and whitelisting two certificates in the Privileged Extension.

[thestinger]

@eighthave OS updates are not going to require any user interaction. Android Nougat brings support for unattended, automatic upgrades. The only required user interaction is accepting a reboot after the update is installed, but there are alternatives.

[thestinger]

@eighthave OS updates are not going to require any user interaction. Android Nougat brings support for unattended, automatic upgrades. The only required user interaction is accepting a reboot after the update is installed, but there are alternatives.

[thestinger]

Any bundled apps are going to have to be provided by the base system partitions unless someone implements proper signing and verification for non-bundled apps. Frequent, security updates are already required for the base system (i.e. several times a month). I have no problem with enforcing that people reboot within a certain time period after an unattended upgrade.

If someone cares about this, they should work on adding unattended upgrade support to the Updater app to take advantage of the new Android Nougat update system.

[thestinger]

Any bundled apps are going to have to be provided by the base system partitions unless someone implements proper signing and verification for non-bundled apps. Frequent, security updates are already required for the base system (i.e. several times a month). I have no problem with enforcing that people reboot within a certain time period after an unattended upgrade.

If someone cares about this, they should work on adding unattended upgrade support to the Updater app to take advantage of the new Android Nougat update system.

[thestinger]

(or work on implementing proper signing / verification for non-bundled apps, but that's much harder, and due to backwards compatibility will not be able to provide the requirements to use it for F-Droid)

[thestinger]

(or work on implementing proper signing / verification for non-bundled apps, but that's much harder, and due to backwards compatibility will not be able to provide the requirements to use it for F-Droid)

[eighthave]

If you only want to include apps that are built from source as part of the ROM, then as long as we nail down reproducible builds, the developer's signature can still be used. That's something we're working on as part of the bazaar funding for F-Droid. Then the apps that come with Copperhead can be updated via the regular channels. Reboots are very disruptive, and should be minimized as much as possible. Many users will not reboot their phone, and hold off as long as possible, which defeats the purpose of prompt updates. F-Droid already provides the update channel for all of the embedded apps, that's the way to do app updates.

[eighthave]

If you only want to include apps that are built from source as part of the ROM, then as long as we nail down reproducible builds, the developer's signature can still be used. That's something we're working on as part of the bazaar funding for F-Droid. Then the apps that come with Copperhead can be updated via the regular channels. Reboots are very disruptive, and should be minimized as much as possible. Many users will not reboot their phone, and hold off as long as possible, which defeats the purpose of prompt updates. F-Droid already provides the update channel for all of the embedded apps, that's the way to do app updates.

[thestinger]

There are a two separate things that are not considered acceptable:

• bundled apps with non-verified apks / libraries / oat files (i.e. no dm-verity or equivalent signing for the app), unless a dire need arises to ship a quick update, but an update would still be shipped as part of an OS upgrade right away too
• bundling code where Copperhead doesn't control updates (if we were going to use reproducible builds for F-Droid, we would still sign it with either the releasekey or another key that we control)

Many users will not reboot their phone, and hold off as long
as possible, which defeats the purpose of prompt updates.

I have no problem with enforcing a deadline like 2 days once unattended upgrades are implemented, where it will reboot when the device is idle once the delay elapses.

[thestinger]

There are a two separate things that are not considered acceptable:

• bundled apps with non-verified apks / libraries / oat files (i.e. no dm-verity or equivalent signing for the app), unless a dire need arises to ship a quick update, but an update would still be shipped as part of an OS upgrade right away too
• bundling code where Copperhead doesn't control updates (if we were going to use reproducible builds for F-Droid, we would still sign it with either the releasekey or another key that we control)

Many users will not reboot their phone, and hold off as long
as possible, which defeats the purpose of prompt updates.

I have no problem with enforcing a deadline like 2 days once unattended upgrades are implemented, where it will reboot when the device is idle once the delay elapses.

[thestinger]

F-Droid is a very, very small part of the base system. I'm not going to treat it in a special way. There are already very important security updates that need to be shipped multiple times in a month. I'm not interested in a very incomplete solution to the problem especially when it would destroy other security properties.

[thestinger]

F-Droid is a very, very small part of the base system. I'm not going to treat it in a special way. There are already very important security updates that need to be shipped multiple times in a month. I'm not interested in a very incomplete solution to the problem especially when it would destroy other security properties.

[thestinger]

I'm only going to be convinced by code implementing this without breaking the requirements, not debate about it. I've already considered it heavily before we even migrated to being based on AOSP and I've made up my mind about how these things should be approached. I don't plan on bundling any other apps until far in the future when things like unattended upgrades and an F-Droid server will be implemented.

[thestinger]

I'm only going to be convinced by code implementing this without breaking the requirements, not debate about it. I've already considered it heavily before we even migrated to being based on AOSP and I've made up my mind about how these things should be approached. I don't plan on bundling any other apps until far in the future when things like unattended upgrades and an F-Droid server will be implemented.

[thestinger]

Note that Silence is not an additional bundled app, it displaces Messenger. Chromium replaces the Browser app. There's a single additional bundled app: F-Droid. There is no upstream where we could get Chromium or the WebView and those need way more frequent upgrades than F-Droid, as do a bunch of components like the kernel (multiple times a month for critical Code Aurora Forum patches) that cannot be updated as an app.

[thestinger]

Note that Silence is not an additional bundled app, it displaces Messenger. Chromium replaces the Browser app. There's a single additional bundled app: F-Droid. There is no upstream where we could get Chromium or the WebView and those need way more frequent upgrades than F-Droid, as do a bunch of components like the kernel (multiple times a month for critical Code Aurora Forum patches) that cannot be updated as an app.

[eighthave]

Unattended upgrades are going to be in the next release of F-Droid, i.e v0.102. We were going to have them in v0.101, but we decided to get that one out faster and give the unattended upgrades more time to settle.

[eighthave]

Unattended upgrades are going to be in the next release of F-Droid, i.e v0.102. We were going to have them in v0.101, but we decided to get that one out faster and give the unattended upgrades more time to settle.

[thestinger]

I meant the unattended OS upgrade feature in N FWIW.

[thestinger]

I meant the unattended OS upgrade feature in N FWIW.

[eighthave]

@relan if you're still up for doing this pull request, the easy path is to do it like you originally said: change the flag on the Copperhead F-Droid build to make it non-privileged, then make a fork of https://gitlab.com/fdroid/privileged-extension.git and make the build there only allow the Copperhead signing key. You can use https://github.com/guardianproject/checkey as one easy way to get the signing key, or I can help with other ways.

[eighthave]

@relan if you're still up for doing this pull request, the easy path is to do it like you originally said: change the flag on the Copperhead F-Droid build to make it non-privileged, then make a fork of https://gitlab.com/fdroid/privileged-extension.git and make the build there only allow the Copperhead signing key. You can use https://github.com/guardianproject/checkey as one easy way to get the signing key, or I can help with other ways.

[relan]

Copperhead should fork of the Privileged Extension repo first. After that we will be able to submit pull requests to

1. platform_packages_apps_F-DroidPrivilegedExtension (or whatever they call it) -- replace F-Droid's certificate with a Copperhead's one
2. platform_manifest -- include Privileged Extension into the repositories list
3. platform_build -- include Privileged Extension into the build
4. platform_packages_apps_F-Droid -- remove privileged flag

[relan]

Copperhead should fork of the Privileged Extension repo first. After that we will be able to submit pull requests to

1. platform_packages_apps_F-DroidPrivilegedExtension (or whatever they call it) -- replace F-Droid's certificate with a Copperhead's one
2. platform_manifest -- include Privileged Extension into the repositories list
3. platform_build -- include Privileged Extension into the build
4. platform_packages_apps_F-Droid -- remove privileged flag

[thestinger]

I'll get to this soon, have been very busy with Nougat porting issues.

[thestinger]

I'll get to this soon, have been very busy with Nougat porting issues.

[thestinger]

It's integrated but needs some upstream issues fixed before we can switch over: #528.

[thestinger]

It's integrated but needs some upstream issues fixed before we can switch over: #528.