[Pki-clean-room-devel] Fwd: Re: make-pgp-clean-room suggestions / patches

Fri Mar 2 19:06:50 UTC 2018

These are the messages I previously had rejected; I then posted them to 
debian-security instead, where they got no response other than one that 
I need not be so worried.

-------- Forwarded Message --------
Subject: make-pgp-clean-room suggestions / patches
Date: Sat, 4 Nov 2017 19:36:02 +0000
From: Rebecca N. Palmer <rebecca_palmer at zoho.com>
To: debian-security at lists.debian.org

Background: my sponsor suggested that I apply for DM over a year ago, 
and the reason I haven't done so is that I'm not sure my security is up 
to it, given that anyone who hacks a DM can upload a Trojan.  I only own 
one computer [0] (meaning it gets used for everything from contributing 
to casual web browsing and reading often-spam email) and my skills are 
at the maths-not-sysadmin end of programming.  I have recently been 
reading up on security with intent to resolve this.

Given the very security-sensitive nature of this project, can you point 
me to (or create) some proof that the person behind it is Pocock-the-DD? 
   If such already exists, I can't find it: neither the announcement 
messages [2] nor the commits are signed, there isn't a Debian package, 
and Alioth doesn't show the userid (the one where lack of -guest = DD) 
of commits anywhere I can find.

Is it appropriate for new contributors to edit this project's wiki page 
[9]?  If yes, I would probably add some of this there.

Is the reason this is still a jessie image simply "nobody has touched it 
since stretch release", or does it actually break in stretch?

paperkey doesn't straightforwardly work with GnuPG2 keys [3]; I don't 
know if there's a way round this or whether printing "base64 
~/.gnupg/private-keys-v1.d/[keygrip]" (in an OCR-friendly font, it's 
~3000 characters per RSA4096 key) would be a better suggestion.

--------------------

Removing networking: this boots for me, but I haven't tested it much 
beyond that, or checked whether it actually does disable networking 
(there are some built-in net modules, which it won't remove, and it also 
might need an initramfs update).  Warning: make sure this is a chroot 
hook, not a binary hook!

config/hooks/live/0020-delete-network-modules.hook.chroot:
#!/bin/sh

rm -rf /lib/modules/*/kernel/net
rm -rf /lib/modules/*/kernel/drivers/net
rm -rf /lib/modules/*/kernel/drivers/bluetooth

---------------------

usbguard tool for choosing what USB devices to allow [4]:
-Each rule allows a kind of USB devices, which can be as general as "all 
printers" or as specific as "Yubikey serial #xxx" (a tool is provided to 
generate the latter kind for the currently connected devices).
-A rule may allow either an unlimited number of its kind of device or 
only one, but the latter is "first one found wins", *not* "if there's 
more than one, block them all".
-There is a global setting for whether the rules apply to devices 
already present at boot time (default off).

Given that the obvious way for malicious USB firmware to get into the 
rest of the system is for the infected device to claim to be a keyboard, 
and we don't want to totally block USB keyboards because this will often 
block the only real keyboard, the best setup for a distributable image 
is probably "allow all at boot, only classes 7,8,9,B (printer, storage, 
hub, smart card) after" and tell the user not to insert the 
data-transfer USB stick until after booting (a good idea anyway to make 
sure you can't *boot* from malicious content on that stick).

This would be (untested!) adding usbguard to the package list and

resources/config/includes.chroot/etc/usbguard/rules.conf:
allow with-interface equals { 07:*:* }
allow with-interface equals { 08:*:* }
allow with-interface equals { 09:*:* }
allow with-interface equals { 0b:*:* }

For users generating their own image, we could also offer the option of 
"only classes 7,8,9,B plus (if needed) my particular USB keyboard, 
including at boot", but this would be a lower priority.

The Intel ME/AMT issue:
-It nominally doesn't use wireless unless either the OS does or it's 
been explicitly told to [5].
-Check whether it's on [6], and if it is, ask the user to turn it off in 
the BIOS settings before proceeding?
-Actually deleting it is claimed to be possible [7], but involves 
physically connecting a programmer to the flash chip (~$40 of hardware, 
on some laptops disassembling parts that weren't meant for end users to 
disassemble, and may brick the system if you make a mistake).
I haven't investigated the AMD equivalent.

As these don't cover all places malicious firmware could be hiding, 
there would be some benefit to using a dedicated computer for this 
(possibly an ARM board to have less firmware in the first place, but 
live-build can't cross build), but given that an attacker sophisticated 
enough to try a firmware attack may well also be sophisticated enough to 
try modifying your package on your main system and waiting for you to 
sign it (which isn't outright stealing your key but is still a way to 
sneak malware into the archive), a better split for a DD with two 
machines might be "all development on one, browsing/gaming/general 
entertainment on the other".

--------------------

A possible "what else is a separate extra-high-security install useful 
for?" feature: an option to run a rootkit scan (e.g. chkrootkit) and/or 
integrity check (e.g. tiger deb_checkmd5sums [8]) on one's main install.

-------------------

[0] not counting phones and microcontrollers; some of the latter were 
bought with intent to modify Gnuk into a not-quite-token (that would 
allow copying but only via a physically separate port) and generate my 
key there so it never touched a general-purpose computer, but given the 
risk of subtle RNG bugs creating a valid but easy-to-crack key, I was 
never sure whether this was a good idea, and after [1] now believe it isn't.
[1] https://lists.debian.org/debian-project/2017/10/msg00014.html
[2] https://lists.debian.org/debian-devel/2016/04/msg00382.html
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879512#15
[4] https://dkopecek.github.io/usbguard/documentation/rule-language.html
[5] https://mjg59.dreamwidth.org/48837.html
[6] (warning, found via Wikipedia and not checked for trustworthiness) 
https://github.com/mjg59/mei-amt-check
[7] https://github.com/corna/me_cleaner/wiki/How-to-apply-me_cleaner 
https://puri.sm/posts/purism-librem-laptops-completely-disable-intel-management-engine/
[8] 
https://sources.debian.net/src/tiger/1:3.2.3-14.3/systems/Linux/2/deb_checkmd5sums/ 
Suggesting this one because it checks against the package management 
system's "what should be there?" and not "has anything changed?" - the 
latter complain about legitimate security updates, and there are enough 
of those that using such tools to check a full desktop is likely to be 
impractical.  However, it only checks the files -> dpkg database link, 
not the full chain through Packages and Release to 
debian-archive-keyring: are there any checkers that do?
[9] https://wiki.debian.org/OpenPGP/CleanRoomLiveEnvironment The 
project-specific mailing list named there rejected this - is this a 
deliberate members-only policy, or part of the Alioth shutdown?