Small Fixes

This is my “to-do list” of small fixes that need to be done before the current set of features provided by DeityGuard can be considered done and finished:

  • Improve the documentation on the website. Once that’s done, include the documentation in the DeityGuard source archive.

  • Once the source code is reasonably cleaned up (an ongoing process), start using a public git repository to manage it. (Right now the DeityGuard source archive is assembled from a bunch of different subdirectories of my private git repository that isn’t being maintained at standards appropriate to a public git repository.)

  • Support including source package files in buildroot rootfs images (needed for GPL compliance allowing binary distributions of DeityGuard). (DONE!)

  • Split the veysp test configs into separate 2GiB RAM and 4GiB RAM versions. (DONE!)

  • Make veysp global configs. (DONE!)

  • The kexec substitute used on the veysp platform reserves some 64MiB of RAM in the device tree. Right now this memory isn’t reclaimed after the OS has booted up properly. A loadable kernel module must be written to free up this memory. (Obviously, this is a very low priority task since 64MiB is just a few percent of the total memory in a veysp machine).

  • Write and include sgdisk and gdisk wrappers for the veysp platform that work around the locked eMMC initial region problem. This is a high-priority task as the veysp platform cannot be considered fully functional without these. (DONE!)

  • Remove bindist USE flag from firefox build as it doesn’t seem to do anything useful (brokenness of bindist seems to be a recurring theme in Gentoo). (DONE!)

  • Find out how to turn off “telemetry” and any other similar privacy-destroying features of the firefox and chromium browsers and script the configuration of initial profiles that have these settings disabled. Simply removing bindist from firefox might be a start. (DONE!) (To be specific, only firefox’s privacy has been tightened up thanks to the existing project ghacks-user.js. There is a project called ungoogled-chromium that is about degreasing chromium, but writing an ebuild for it in Gentoo sounds like a new feature. Basically, a quick fix can’t be done here because it appears the privacy aspects of chromium are not actually run-time configurable. Someone’s attempts to maintain an ebuild for chromium with patches here are not encouraging in terms of the effort that needs to be expended; I don’t have time to do something like that. As far as I can tell one of the main problems is that the ungoogled-chromium patchset does not always track the same version of chromium as portage, which makes it a trial and error process to blend patches and build dependencies from different chromium versions.).

New Features

This is a list of new features that might or might not happen, but here they are:

  • Remove expanded modules from unikit and keep only modules.sqs; make fingen unpack modules from modules.sqs; revert unikit to being a plain tar archive. This will should shrink the size of the unikit considerably and speed up the process of building it, too.

  • Include vlock in the standard build, or write and include a suitable substitute (I have one lying around from a different project).

  • Eliminate the use of third party applications (i.e., busybox) for anything that goes over the network over the entire boot process. This means implementing equivalents for dhcpc, wget, and ntpdate as secure libaboon-based “tools”. This should tighten up security a lot; busybox especially has historically had a number of critical security vulnerabilities.

  • Support for locking the flash on platforms with a BIOS chip boot. This seems do-able on all three BIOS chip platforms but may require slight hardware modifications/adjustments on some platforms.

  • ZFS-on-Linux (a.k.a. ZoL) support. There is already some code in for supporting ZoL in a way that doesn’t introduce licensing issues, but a lot more work is needed. The licensing issues with ZoL can be worked around by compiling the ZoL module on the client before loading it. Thus the ZoL module binary is never distributed together with the kernel binary (which is arguably might form a combined work whose distribution in binary form could violate the GPL). The client should cache the compiled ZoL module somewheres. The ZoL module is built once in gengen as part of building the kernel, but the results are thrown away – the ZoL module is compiled only for the purpose of determining which kernel source tree files are required for compiling the ZoL module. The required kernel source tree files are then included in a special “header” archive that can be distributed with the kernel binary, and that can later be used to compile the ZoL module on the client without needing a complete and configured kernel source tree. Neat eh? The additional work to get ZoL working is fully justifiable artistically because ZFS is the only filesystem supportable in Linux that won’t return bad data to the userspace. With, e.g., ext4, a malicious storage device firmware could inject errors even through a layer of block-level encryption (i.e., LUKS). Moreover, ZFS supports protecting against bitrot with copies=N which is also lacking in ext4. Some RAID support apparently exists in btrfs but it can’t be made to work like copies=N and btrfs has a lot of other limitations that ZFS doesn’t. (DONE!)

Beyond DeityGuard

DeityGuard is about making sure all the code you run is loaded securely. While that’s an important security benchmark, you also need the loaded code itself to be secure! Sadly, even basic tools like the OpenSSH client can’t be fully trusted (see here, in particular the “January 14, 2016” entry), let alone the OpenSSH server.

A pessimist could say that the main effect of running DeityGuard is that instead of being owned when you press the power button, you are owned when you use the ssh client, when you use the git client, when you open the web browser, etc. And if a pessimist could say it, it’s probably true!

What’s needed onwards from DeityGuard is a whitelist of network client software that:

  • has a small, clean, and auditable code base,
  • has a strong focus on security, and
  • doesn’t have a ton of useless or fringe features (a.k.a. “attack magnets”).

The above would apply to simple tools like SSH and git clients. In terms of web clients (“browsers”), the situation is trickier because they are insecure by definition. The HTML5 specifications are simply too complex to be implemented securely at our current level of technology. I would even say HTML5 is not securely implementable at any projected future level of technology over at least the next 20 years.

So the security expectations needs to be relaxed a bit for browsers; the focus has to be on mitigating the possible effects of an attack rather than expecting to prevent attacks altogether.

What should be done is to rig up a popular browser to run in a virtual machine and render to a networked framebuffer (like how VNC works), and implement proper window resizing and such and try to offer an experience as close as possible to local use while keeping the client as lean as possible.

In spirit, this suggestion is similar to Qubes works. However, in the context of DeityGuard it’s too limiting to assume that the VMs run on the local machine. Only one of the four platforms supported in DeityGuard is actually amenable to running browsers in VMs, and that would be the bulky and noisy d16 that you really don’t want to have on or under your desk anyway. But something that interfaces to per-browser-tab VMs dynamically launched on a remote d16 machine would be quite useful.

Well, wrapping up DeityGuard is the first step, I guess.