apt-revoker - Check for Revocation Certificates before running apt-get
Open, NormalPublic

Description

Migrated from:
https://github.com/Whonix/Whonix/issues/125


Debian has no good mechanism to revoke apt keys in case of compromise, neither a way to inform users in emergency situations:
https://lists.debian.org/debian-security/2013/10/msg00065.html

An apt key revoker should be written:
https://lists.debian.org/debian-security/2013/12/msg00031.html

And up-streamed to Debian.

  • Keyservers may not be used: https://lists.nongnu.org/archive/html/sks-devel/2013-12/msg00076.html
  • The code for downloading the revocation certificates should be configurable.
  • .d style configuration folder. Where distributions and PPA's can drop configuration snippets. Using arrays.
  • Code should be re-usable for Whonix News key revocation as well (using configuration snippet).

Related:


Implementation:
One should discuss this with debian-security list / debian apt developers (sh vs bash [arrays] vs python vs ...) as more sophisticated implementation plans materialized.

Details

Impact
Needs Triage
Patrick created this task.Feb 7 2015, 3:24 AM
Patrick updated the task description. (Show Details)
Patrick raised the priority of this task from to Needs Triage.
Patrick added projects: security, bash, python.
Patrick added a subscriber: Patrick.
Patrick triaged this task as Normal priority.Feb 7 2015, 4:32 PM
Patrick renamed this task from Check for Revocation Certificates before running apt-get to apt-revoker - Check for Revocation Certificates before running apt-get.Mar 5 2015, 1:18 PM
Patrick set Impact to Needs Triage.Dec 15 2016, 5:53 PM
Patrick added a subscriber: HulaHoop.

I want to help with the brainstorming for this. It will get more attention especially with the recent CVEs. This particular utility is a good candidate for Core Infrastructure funding IMO.

This comment was removed by HulaHoop.
HulaHoop updated the task description. (Show Details)Dec 17 2016, 12:27 AM

Removed previous comment. The task is big enough no need to bite more than we can chew.


  • To avoid getting into a trust bootstrapping nightmare - its not enough to revoke a key but also send a new one via the emergency notification system to replace the revoked one. The emergency notification messages should be signed with a different key than the one for repo package signing old and new. In a sense the emergency key is a master key that should be very well guarded and only used in such situations - because it has authority over repo keys. Its sounds bad but I don't have better ideas for this.
  • Should revocation be automated? IMO nothing should ever be done automatically. Fortunately apt in Whonix doesn't do automatic updates. Imagine how bad that would have been!
  • The key handling/revoking should be done via GPG itself of course. We should only be concerned about the scripting that handles a remote emergency command and its execution on the machine.
  • Language choice: Up to you. Whichever you are comfortable with is best unless upstream is prejudiced against one or the other for security reasons.
  • I did not get the feeling that keyserver use is unwelcome however this is just one pool - there are still many other operators. Also it might be a redundancy with either centralized server-client used instead or a decentralized storage alternative. The priority is to support server-client model first because this is likely what the most common usecase will be.

HulaHoop (HulaHoop):

  • To avoid getting into a trust bootstrapping nightmare - its not enough to revoke a key but also send a new one via the emergency notification system to replace the revoked one.

Emergency news should only inform about the new key. Not add the new
key. Otherwise that functionality would exceed the competence of
emergency news.

The emergency
notification messages should be signed with a different key than the
one for repo package signing old and new.

added here:
https://www.whonix.org/wiki/Dev/emergency-news

In a sense the emergency
key is a master key that should be very well guarded and only used in
such situations - because it has authority over repo keys. Its sounds
bad but I don't have better ideas for this.

Should use multi sig (key splitting).

The Debian apt signing key is on an official debian.org server. The
revocation key is on Debian Developer's (DD) machines. (Not necessarily
offline machines.)

They would need at least a 7/12 signature to create the Debian apt
signing key revocation certificate.

Source:
https://ftp-master.debian.org/keys.html

So by using multi sig and not keeping the the emergency news signing key
only on DD's machines, it would be safer than Debian's apt signing key.

Added here:
https://www.whonix.org/wiki/Dev/emergency-news

  • Should revocation be automated? IMO nothing should ever be done automatically. Fortunately apt in Whonix doesn't do automatic updates. Imagine how bad that would have been!

Perhaps it should be checked for revocation certificates on every run of
apt-get update but not otherwise automated? [Unless users opted in for
auto apt updates but then that's there choice - no difference to the
current situation.]

  • The key handling/revoking should be done via GPG itself of course. We should only be concerned about the scripting that handles a remote emergency command and its execution on the machine.

I'd advice against signing the emergency news on any official debian.org
system. That should be done be done only on demand by DDs. Does that
address your point?

  • Language choice: Up to you. Whichever you are comfortable with is best unless upstream is prejudiced against one or the other for security reasons.

What do you mean by language choice? Do you mean the final wording of
the proposal?

I am not eager to do the clean wording of the proposals.

  • I did not get the feeling that keyserver use is unwelcome however this is just one pool - there are still many other operators. Also it might be a redundancy with either centralized server-client used instead or a decentralized storage alternative. The priority is to support server-client model first because this is likely what the most common usecase will be.

Made a note here:
https://www.whonix.org/wiki/Dev/apt-revoker

We now have two proposals.

There will be some overlap.

I guess we should present only one concept at a time? Perhaps start with
apt-revoker?

(Doesn't mean we cannot already discuss/write the emergency-news
proposal. We can discuss/write any concept as thoughts are incoming.)

Perhaps it should be checked for revocation certificates on every run of apt-get update but not otherwise automated?

By "automating" it can run with apt-update even with an apt.cron setup maybe?

What do you mean by language choice?

Bash vs Python

I guess we should present only one concept at a time? Perhaps start with apt-revoker?

Yes.

There will be some overlap.

Both tools can be used together in some situations but they are very different in what they do. If this is presented clear enough the overlap in people's minds should be eliminated.

(Doesn't mean we cannot already discuss/write the emergency-news proposal. We can discuss/write any concept as thoughts are incoming.)

Right.

Perhaps it should be checked for revocation certificates on every run of apt-get update but not otherwise automated?

By "automating" it can run with apt-update even with an apt.cron setup maybe?

If apt.cron runs apt-get update, then yes. apt.cron -> apt-get update -> apt-revoker -> real apt-get updating.

What do you mean by language choice?

Bash vs Python

I would leave this open.

Renamed from emergency news to project news. It does not have to be limited to emergencies if it's configureable. Users could subscribe to various channels, i.e. emergencies only, testers wanted etc.

https://www.whonix.org/wiki/Dev/project-news

Added more points:

Should only distributions be allowed to drop in news plugins or application packages also?

Should only distributions be allowed to drop in news plugins or application packages also?

Applications too. Its useful when upstream wants to communicate non backwards-compatible changes. Though it would be good to make this configurable allowed/not allowed in case distros have a problem with package news not going thru them first.