Feature #7687

Remove ekeyd

Added by sajolida 2014-07-29 17:47:20 . Updated 2016-11-15 10:57:39 .

Status:
Resolved
Priority:
Normal
Assignee:
intrigeri
Category:
Hardware support
Target version:
Start date:
2014-07-29
Due date:
% Done:

100%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
0
Affected tool:
Deliverable for:

Description

In a WhisperBack bug report, someone suggested to remove ekeyd from Tails

Tails automatically starts up ekeyd, the Entropy Key Daemon, which looks for any attached Entropy Key device and uses it as a source of randomness for the kernel. This is all well and good, except for one fact: no one uses Entropy Key. Not only is it rare, but it’s been out of stock for a very long time, and unlikely to come back soon. There are far more popular external TRNGs out there, many of which have their own daemons. That makes you think, why should Tails have an extra daemon running as root, who’s purpose is to mess with the kernel entropy pool, if it’s so seldom ever used? All it takes is an attacker to find a bug that allows them to fill the entropy pool with bogus data, which isn’t unlikely when ekeyd has /dev/random open for writing constantly and constantly keeps looking for an Entropy Key.

Please remove ekeyd. It’s unneccessary and its presence just increases the attack surface area of Tails.


Subtasks


Related issues

Related to Tails - Feature #5650: rngd Resolved
Related to Tails - Feature #11703: Consider not starting ekeyd by default Rejected 2016-08-23

History

#1 Updated by sajolida 2014-07-29 17:47:36

#2 Updated by ioerror 2014-08-04 21:54:09

I use ekeyd regularly. It is extremely useful. Please do not remove it.

#3 Updated by sajolida 2014-08-06 08:14:52

  • Status changed from Confirmed to Rejected

Thanks for the info.

Rejected then :)

#4 Updated by sajolida 2016-09-01 07:23:47

  • related to Feature #11703: Consider not starting ekeyd by default added

#5 Updated by sajolida 2016-09-01 07:36:03

  • Status changed from Rejected to Confirmed
  • Type of work changed from Research to Discuss

Given Feature #11703, let’s reopen this ticket :)

According to archive.org Entropy Keys have been out of stock since March 2013: https://web.archive.org/web/20130330233729/http://www.entropykey.co.uk/shop/.

And according to tracker.debian.org the upstream code is not available anymore: https://tracker.debian.org/pkg/ekeyd.

Still, according to popcon, the package is still installed frequently: https://qa.debian.org/popcon.php?package=ekeyd.

Maybe it’s time to reconsider removing ekeyd and suggest people who still have entropy keys to install it using Additional Software Packages? This might not work for people using Entropy Key on air-gapped machines (but how many people would that be…) Or shall we wait some more? If so, until when?

As a first step, should we disable the daemon by default, as suggested in Feature #11703, and ask people to complain if they miss it.

#6 Updated by intrigeri 2016-09-10 07:26:05

  • related to deleted (Feature #11703: Consider not starting ekeyd by default)

#7 Updated by intrigeri 2016-09-10 07:26:09

I support removing ekeyd, on the grounds that it’s unmaintained, very rarely used, poorly designed, and security sensitive. Given how it’s (not) maintained, I bet that it’ll bitrot, and sooner or later it’ll be removed from Debian testing anyway.

(Nitpicking starts here ;)

But I’d rather not build this decision on top of some of the other suggested arguments, that could set precedents I’m not comfortable with:

  • We go to great lengths to support various hardware, including some that’s been out of stock since quite before 2013, and to do that we often accommodate ourselves of some, or all, of the drawbacks ekeyd suffers from (e.g. we ship binary firmware blobs and all kinds of mostly obsolete driver code that runs as root, when not in kernel space. By nature, these pieces of code are very dangerous, but pragmatically we have to live with it). I guess we can easily agree that we should try to support hardware even if it’s 4 years old, even if this implies to ship this kind of code.
  • Let’s not get used to suggest Additional Software Package for hardware support, especially hardware that’s particularly useful for air-gapped systems.

#8 Updated by intrigeri 2016-09-10 07:26:14

#9 Updated by sajolida 2016-09-11 02:59:35

  • Subject changed from Consider removing ekeyd to Remove ekeyd
  • Type of work changed from Discuss to Code

Ok, so the rationale is that we support old hardware as long as the corresponding software is well maintained. Or actually, we include software as long as it is mainained (indenpendently of the corresponding hardware).

Mangling this ticket accordingly then.

#10 Updated by sajolida 2016-09-11 03:01:05

Or maybe intrigeri feels like this needs more discussion since he didn’t close Feature #11703

#11 Updated by intrigeri 2016-09-11 03:48:21

> Or maybe intrigeri feels like this needs more discussion since he didn’t close Feature #11703

No, that’s fine, let’s proceed! I did not close Feature #11703 because I preferred us to decide something here first (and if for some reason we had decided to keep ekeyd, then we could have discussed the option suggested by Feature #11703).

#12 Updated by intrigeri 2016-09-11 03:49:30

  • Assignee set to intrigeri
  • Target version set to Tails_3.0

I’ll do that for Tails 3.0, on the grounds that such major releases are our preferred time to deprecate support for hardware we cannot (or don’t want to) support anymore.

#13 Updated by intrigeri 2016-09-11 03:55:59

  • blocked by deleted (Feature #11703: Consider not starting ekeyd by default)

#14 Updated by intrigeri 2016-09-11 03:56:36

  • related to Feature #11703: Consider not starting ekeyd by default added

#15 Updated by intrigeri 2016-11-15 10:57:05

  • Status changed from Confirmed to Resolved
  • % Done changed from 0 to 100

Applied in changeset commit:ef85d3c90e20d7ee9d323593cabb4b20a1f1ab3b.