Call for Collaboration to Apply to NGI "Privacy & Trust Enchancing Technologies" Grant

[tlaurion]

Grant Information here: https://nlnet.nl/PET/
Form here: https://nlnet.nl/propose/

Framapad for grant proposal collaboration: https://mensuel.framapad.org/p/AQqOdrEBWr

Anyone wants to jump in?

[tlaurion]

Some ideas that needs to be picked up and integrated, don't know how to include them in paper yet:
EDIT: Multiple additions. QubesOS will also apply to this for UX improvements.

Please comment all pertinent ideas!

Heads specific work

• Properly support Intel based, most binary free initialized platforms in coreboot (Ivy Bridge and Sandy Bridge). This implies integrated Measured boot improvements that landed in Coreboot 4.9+, which sits atop of VBOOT and change Head's internal logic to take advantage differently of TPM PCRs to have proper and mainstreamed BIOS integrity measured. Technically, it means:
  • integrate/ test :
    • Add VBOOT support
    • Enable VBOOT support
  • check if fmap is correct
  • set CMOS flags correctly
• [Support TXT in Coreboot/Heads, so that QubesOS Anti-Evil Maid can be used with coreboot Open Source Firmware](Explore QubesOS AEM usb boot #502)
• Integrate write protection, preventing firmware modification from the Operating System through io386 lock down module Introduce io386 to heads and use it to finalize chipset at runtime (PR0 initial work) #326
• Upgrade disk encryption (cryptsetup LUKS) support in Heads:
  • QubesOS dom0 fedora-29/debian-9 based to be able to support LibremKey-enabled LUKS container unlocking so that Heads can take advantage of this in a generic way.
  • Integrate Kali LUKS key slots wipe permitting the user to deny themselves and others system and data access, basically locking themselves out of the system until a full disk backup is restored.
• Reduce Heads Whiptail graphical footprint to fit a broader range of devices having 4Mb SPI flash, including x200 (Tails perfect Laptop. More generally in 4MB flash, while available in 8MB SPI if vPro) and G505s and probably a lot of others.
• Implement forward sealing of firmware upgrades

Hardware mods to streamline/for which open source blueprints needs optimizations

• Fablab test/build/improve NSA-B-GONE camera and mic hardware datalink cutoff through thinklight keyboard shortcut, so it can be easily laser cutted/ordered online from oshpark or elsewhere. Insight is that those could be laser cut and the connector be made out of mica (capacitor) pastic.
• Fablab test/build last blobfree x86 reasonably secure server/workstation (KGPE-D16/KCMA-D8) open sourced iKVM ASMBV4 remote administration chip, so that QubesOS/private hosting solutions/FPF SecureDrop Workstation/Servers have trustable root of trust in Heads. Current unmaintained OpenBMC port exists for that module, where some work would need to be done for that server to boot u-root

QubesOS related work

Create and deploy additional Salt recipes at QubesOS installation/new defaults that

• Grow QubesOS user base by developing third party assistance services base.
  • Develop Whonix (sys-whonix) on-demand hidden onion GUI, opening dom0 remote support through SSH and socat. Whonix ticket here.
• Properly handle qube's LVM freed space at all levels, reducing catastrophic user experience of running out of of disk space.
• Deploy qubes-update-cache and make update-vm dependent on it, so that packages are downloaded once per TemplateVM types (fedora, debian, whonix-gw, whonix-ws) even if many clones were created and specialized out of them. Keeping one's system up to date then requires only minimal bandwidth.
• Deploy good privacy default for NetworkManager, forcing randomized mac usage when not told otherwise.

Sent from my Galaxy S3 using FastHub-Libre

[tlaurion]

@merge @marmarek @osresearch @kakaroto @mfc :
Any other improvements you would love to see happening into Heads Heads/QubesOS, integration of better privacy/confidentiality enforcing measures that would benefit all privacy conscious?

[merge]

what comes to mind, but that's more of a question: how far are we with "forbid software-flashing everywhere except in one root-of-trust place inside the flash"?, for the coreboot side, it started with this discussion: https://coreboot.coreboot.narkive.com/ovqZj0CI/spi-controller-and-lock-bits and I don't know how far that is. In Heads we should use that and maybe, when we read a grub config off disk, think about warning/forbidding kernel parameters like "iomem=relaxed"... thanks.

[tlaurion]

what comes to mind, but that's more of a question: how far are we with "forbid software-flashing everywhere except in one root-of-trust place inside the flash"?, for the coreboot side, it started with this discussion: https://coreboot.coreboot.narkive.com/ovqZj0CI/spi-controller-and-lock-bits and I don't know how far that is.

@merge : #326? Never tested it though.

In Heads we should use that and maybe, when we read a grub config off disk, think about warning/forbidding kernel parameters like "iomem=relaxed"... thanks.

@merge : It could be as easy as putting that here:
export CONFIG_BOOT_KERNEL_REMOVE="iomem=relaxed"

[marmarek]

@merge : It could be as easy as putting that here:
export CONFIG_BOOT_KERNEL_REMOVE="iomem=relaxed"

This isn't viable solution - there are way too many potentially harmful kernel options. If anything, there should be a whitelist of allowed options.

[merge]

thanks for the links and updates. sorry for the confusion. actually it's quite unrelated and not a good idea to mess with user's kernel commandline so much. All we need for a proper root of trust is (persistent until reboot-)write-protection of the flash as soon as possible unless the user chooses "upgrade" or something. Once we have that, it should really be irrelevant what iomem or others say.

We really need to verify whether that works for the X230's flash chips, and implement a user-friendly solution.

[tlaurion]

@merge : It could be as easy as putting that here:
export CONFIG_BOOT_KERNEL_REMOVE="iomem=relaxed"

This isn't viable solution - there are way too many potentially harmful kernel options. If anything, there should be a whitelist of allowed options.

@marmarek: agreed. But:

• Potentially harmful added kernel options arrives into grub configuration per logged in user upgrades or manual Head's recovery shell manipulations.
• /boot changes are detected here. Since /boot hashes are generated at each boot and validated against user's signed kexec.sig, no file under /boot can be changed without the user approving/knowing what changed.

Following this, a whitelist seems overkill, io386 actually prohibits iomem=relaxed from being successfully used to reprogram the SPI flash from within OSes other then Heads which locks it. Following this, if io386 is in, removing iomem=relaxed from KERNEL_REMOVE is useless.

[mfc]

hey folks, just chipping in that the Qubes proposal I will draft will be focused on Qubes usability (integrating existing efforts that still haven't been reviewed/incorporated into the release) and internationalization/localization/accessibility support. so it will be a bit "conservative" in approach but filling in some very necessary gaps Qubes has.

I don't expect any overlap with these topics so the Heads/Qubes proposal can be as ambitious as desired! :)

[snmcmillan]

I think that one idea for heads-specific work is to port to more devices. Ideally, support more ThinkPads and as many Chromebooks as feasibly possible.

On the ThinkPad side of things, since xx20 and xx30 are incredibly similar, it should be rather simple to port kernel configs to T420 (I currently have a PR for that), T430 (someone else seems to be on that), T420s/T430s, T520 and T530. I presume the T410, T510 and X201(s/t) should also be trivial as well (they may even work with the same config to the X230 config that the X220 and the T420 are using currently).

For Chromebooks, the most ideal and easiest way to do this is to collaborate with Mr. Chromebox, which maintains custom coreboot builds for many, many Chromebooks. If we can get the patches used for heads to be merged into mainline coreboot, that effort would be very easy, all that's needed is for someone to update Mr. Chromebox's repo (either via a fork or getting the new base to the main repo) and having a mostly universal kernel config for them to use when building the kernel.

Having several different hardware options for users to choose from would not only open heads up to more users, but it could also lead it to being more streamlined than it currently is.

Another thought I just had was to get Heads (and even possibly Qubes) running on ARM devices (namely ARM Chromebooks). ARM-based Chromebooks may remove the threat of IME/PSP, unless they also have a hardware level backdoor that I'm presently unaware of.

On the Qubes side of things (independent of Heads), one thing is to get the GUI out of dom0. I've heard chatter about this from various places, but this would be huge.

Another thing worthy of being implemented is proper touch screen and stylus proxy support. I do know that this would be very difficult considering USB input device security is already a problem in itself.

I apologize for this text wall and if it's difficult to read.

[tlaurion]

I think that one idea for heads-specific work is to port to more devices. Ideally, support more ThinkPads and as many Chromebooks as feasibly possible.

@SebastianMcMillan : Agreed, with some personal limitations, see below.

On the ThinkPad side of things, since xx20 and xx30 are incredibly similar, it should be rather simple to port kernel configs to T420 (I currently have a PR for that), T430 (someone else seems to be on that), T420s/T430s, T520 and T530. I presume the T410, T510 and X201(s/t) should also be trivial as well (they may even work with the same config to the X230 config that the X220 and the T420 are using currently).

For Chromebooks, the most ideal and easiest way to do this is to collaborate with Mr. Chromebox, which maintains custom coreboot builds for many, many Chromebooks. If we can get the patches used for heads to be merged into mainline coreboot, that effort would be very easy, all that's needed is for someone to update Mr. Chromebox's repo (either via a fork or getting the new base to the main repo) and having a mostly universal kernel config for them to use when building the kernel.

Having several different hardware options for users to choose from would not only open heads up to more users, but it could also lead it to being more streamlined than it currently is.

Agreed, while again, the most free platforms (binary free of Intel FSP/no AMD PSP, me_cleaner neuterable Intel ME platorms containing only ROMP and BUP modules) should be priorized in that list. This is why I push so much the x230 right now and think that Ivy bridge first, and then sandy bridge second, based laptops should be supported more.

This doesn't mean that other platforms should not be added in parallel. My point here is that my own priority is to push most trustable hardware available today (binary blobfree 4.9 coreboot (graphic init, native ram init, etc) with Measured boot support, TXT support(optional), TPMv2 support) well supported/tested before integrating other platforms.

I invite others to collaborate on that and will gladly add those platforms in the points to be covered for the grant but won't do that work myself nor will be able to test those platforms, while inviting the community to do it and be paid for those contributions.

Another thought I just had was to get Heads (and even possibly Qubes) running on ARM devices (namely ARM Chromebooks).

Follow GSoC progress for ARM64 here. I'm personally more interested into PPC64 port, for the same reasons evoked above with even more user ownership possibilities (PowerPC notebook, Power9 completely open designs like the Talos II/BlackBird and others).

ARM-based Chromebooks may remove the threat of IME/PSP, unless they also have a hardware level backdoor that I'm presently unaware of.

TrustZone is IME equivalent.
This is an interesting file to follow, but not all ARM architectures include virtualization extension, and from what I saw, the ones that does, for laptops, don't have enough memory to be minimally interesting for QubesOS(8Gb+). But that might change in the future.

On the Qubes side of things (independent of Heads), one thing is to get the GUI out of dom0. I've heard chatter about this from various places, but this would be huge.

It's planned for QubesOS 4.1.
EDIT see here: https://groups.google.com/d/msg/qubes-devel/CA7gHGQk5WE/JEfADyFaBAAJ

Another thing worthy of being implemented is proper touch screen and stylus proxy support. I do know that this would be very difficult considering USB input device security is already a problem in itself.

I've roughly tested this myself and it works:
Scripts
Tablet support in QubesOS

I apologize for this text wall and if it's difficult to read.

No problem. :)

Edit: priorities

Sent from my Galaxy S3 using FastHub-Libre