apt-revoker - Check for Revocation Certificates before running apt-get

[phabricator-migrator]

Information

ID: 140
PHID: PHID-TASK-fmfckf46hede24dqp4hj
Author: Patrick
Status at Migration Time: open
Priority at Migration Time: Normal

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: [Sks-devel] How much load are keyservers willing to handle?
• 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:

• https://packages.debian.org/sid/parcimonie
• GitHub - EtiennePerot/parcimonie.sh: Refresh your GnuPG keyring without disclosing your whole contact list to the world
• Dev/project-news - Kicksecure

---

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.

Comments

---

HulaHoop

2016-12-16 02:55:57 UTC

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.

---

HulaHoop

2016-12-16 23:27:54 UTC

---

HulaHoop

2016-12-16 23:50:40 UTC

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.

---

Patrick

2016-12-17 01:02:41 UTC

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:
Dev/project-news - Kicksecure

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:
ftp-master.debian.org Archive Signing Keys

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:
Dev/project-news - Kicksecure

• 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:
Dev/apt-revoker - Whonix

We now have two proposals.

• Dev/project-news - Kicksecure
• Dev/apt-revoker - Whonix

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.)

---

HulaHoop

2016-12-18 00:37:08 UTC

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.

---

Patrick

2016-12-18 12:53:32 UTC

! In T140#11042, @HulaHoop wrote:
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.

---

Patrick

2016-12-18 13:38:24 UTC

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.

Dev/project-news - Kicksecure

Added more points:

• Dev/project-news: Difference between revisions - Whonix
• Dev/project-news: Difference between revisions - Whonix
• Dev/project-news: Difference between revisions - Whonix

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

---

HulaHoop

2016-12-18 15:13:50 UTC

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.

---

Patrick

2016-12-18 15:38:48 UTC

Ok, added.