On 04/25/2016 06:38 PM, Daniel Pocock wrote: > On 25/04/16 17:34, Christian Seiler wrote: >> Am 2016-04-25 17:24, schrieb Daniel Pocock: >>> On 25/04/16 16:23, Holger Levsen wrote: >>>> On Mon, Apr 25, 2016 at 04:03:26PM +0200, Daniel Pocock wrote: >>>>> I had already made up some live CDs for ready-to-run VoIP and >>>>> remote hands purposes, so I can probably do some of what is >>>>> required, but it seems like a good idea to avoid duplicating any >>>>> other efforts in this area too. >>>> >>>> shouldn't most of the functionality of this go into (a) dedicated >>>> package(s) which then can be used by several, eg by tails and grml and >>>> debian live-cds? >>>> >>> Some parts of such a project could probably be packaged >>> >>> One of the ideas I had is that it should have a kernel compiled without >>> any networking support, then it may not make sense to mix bits of the >>> solution with other live CDs >> >> Well, as Debian kernels are modularized, why not simply create a >> package that blacklists all network drivers? Then you don't have >> to compile an own kernel, but just make sure that the list of >> networking-related kernel modules is up to date, which seems to >> me to be a lot less work (especially since you can potentially >> automate that by looking for stuff in drivers/net). >> >> Plus a tool that looks at the list of loaded modules and checks >> that there isn't any network driver loaded. >> > > I agree that is probably easier for development, although from a > security point of view the strategy would be to avoid having any > networking code in the environment at all
Well, your live CD creator script could also drop the networking modules from the image, then they aren't available on the live CD/USB key at all. Unless there is some driver compiled into the kernel (I haven't checked), this should also be sufficient. > I've progressed the whole concept from vapourware to wikiware now: > > https://wiki.debian.org/OpenPGP/CleanRoomLiveEnvironment > > Does the workflow make sense? In principle yes, however it doesn't quite fit with my the workflow I'd like to use something like that for: my master key is on a two separate SD cards, and I only have one SD card reader. So what I do when I need to change something on the key is to insert one SD card, copy the .gnupg directory to a tmpfs, do the modifications, copy the directory back to the first SD card, and then copy the directory back to the second SD card. Any RAID solution wouldn't work for me, as I can't insert both cards at the same time. (Also, many people only have a limited amount of USB ports, and not every person wants to buy a hub just for this, so even with USB keys RAID might not always be easily possible, especially if you need one port for booting the system.) By the way, in addition to the passphrase for the GPG key, my SD cards are also encrypted via LUKS (with a different passphrase) to provide an additional layer of security. (For example, if gpg had some bug that left some information behind in .gnupg pertaining to the key, this would still prevent people that get a hold of the card to access those.) LUKS should probably be optional, but something to think about. Finally, I'm not sure I'd trust btrfs enough for this - especially in RAID mode if both devices are your only copy. I can't think of any feature in btrfs that might be required for this use case, so I'd rather stick with a plain ext4, at least by default. When it comes to this I'd rather be conservative. Regards, Christian
signature.asc
Description: OpenPGP digital signature
