[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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!


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

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: