make-pgp-clean-room suggestions / patches
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?
Reply to: