Is removing laptop components for system hardening a good idea?

General Discussion
1

Recently, I found Insurgo which sells laptops installed with Coreboot and QubesOS.
I was inspired, by an old service offered by Minifree to remove hardware components to harden your Thinkpad, to ask Insurgo if they would ever do the same for their products including replace Coreboot with osboot.

The reply I got was very interesting. Their English wasn’t great but what I could gather was this.
First off, I wanted them to remove the speakers, Wi-Fi and Bluetooth modules, expressCard and Firewire slots, webcam and microphone.

So they told me these following points…

  • Microphones and Speakers are driven by dom0 and EC.
  • The microphone needs an “explicity dispatch” to a Qubes VM prior to being usable(?)
  • Wi-Fi is secluded in a disposable sys-net VM.
  • USB controllers, including the webcam(?), is secluded to sys-usb and require manual and explicit dispatch prior to being usable by a Qubes VM.

So are they telling me I need to have these components intact in order to run QubesOS?
What can anyone tell me?

Thanks.

2

No, they are telling you that you might not need to remove the hardware, if you are using Qubes OS.

A qube can only see the hardware you allow it to see, you can simply choose to not use any of the hardware in “high risk” qubes, and you have very close to the same protection as if the hardware was removed.

You can remove the hardware and still use Qubes OS, but you probably don’t need to do it.

4 Likes
3

In addition to what renehoj just said, it all depends on your threat model and what you’re defending against. If you want to be super paranoid then, yeah, you can remove those components. I had an old T61 laptop that I went that route on - pulling all of those components and desoldering the ethernet chip - until all I had were USB ports.

For me, a machine running Qubes that is physically protected against mischief is “good enough”.

1 Like
4

@ledOnion Hello there!

Of course removing physical components is pertinent for hardening.

The point I tried to make is reflected in previous comments.

The reason I do not offer removal is pretty simple. Maintainership issues and additional testing and separation of duties issues and related liabilities issues in terms of guarantees from refurbisher transferred to my side.

Without giving too much details, I keep original BIOS images and track item associated numbers to order numbers in case anything happens after shipping, and the item is sent back to me, so I can flash it back and resend to refurbisher. Doing as minimal manipulation on the hardware possible, while still testing the hardware extensively and monitoring fan noise and variation of expected performances against initial re-ownership of the hardware through Heads against deployed OEM disk of hardware and re-encryption of the disk image, which is the same for all sold items.

I’m not looking at either complexifying the testing process nor taking additional responsibilities off of the refurbisher here.

I think people are mixing concepts which justifies their requests. I try to not judge those, but there is no security justification behind removing a usb connected camera, even less on Qubes, as opposed to keeping functionality and putting tape on it or a slider, where it is useless confined under sys-usb until it is explicitly passed to the qubes where needed.

Same applies to microphone, where tape is less efficient. One could remove it, but nowadays, it is a needed feature and since it is secluded to dom0 unless explicitely passed to qube needed prior of use, it is not listening to anything, and even if it was, dom0 (as sys-usb) is not connected to internet, and consequently cannot exfiltrate data.

Removing wifi is the same. The standard wifi card is swapped to an open source driver driven minipci card, and secluded to sys-net. I understand the need of a air-gapped system, but if such laptop is needed, the laptop as a whole should be isolated physically, and physical slider on the laptop should be put in off mode.

There is no advantage, as a service provider to provide a distinct OEM image to remove such devices and create and maintain a separate OEM image without those physical components.

On top of that, you asked me to not provide an SSD drive, and to deploy osboot instead of Heads. I replied that you actually didn’t want a PrivacyBeast.

Removing Qubes, SSD drive: not providing a disk image (where relies most of my added value), replacing Heads with osboot, where relies pre-boot security with measured boot with the TPM with encrypted disk image, kinda nullifies in transit tamper detection altogether. Basically stripping off all the work and added value I provide.

I would ask more money to provide less, which is why I directed you to osboot/minifree. It does not make sense to me to provide such service.

You wanted a x230 with osboot and hardware components removed. You did not wanted a PrivacyBeast. Or didn’t understand what a PrivacyBeast offered.

It is not the first nor the last time that this is unclear for users, even though the website is pretty clear on the offer, where the product page restates it in even more details. People don’t read. This is my conclusion.

Hope this will be read from others requesting the same.

The service I provide is added value on top of refurbished x230 hardware, with pre-installed and up to date Qubes deployment, with transit tamper evidence where nobody in transit can modify boot nor pre-boot environment without being tamper evident. Encrypted Qubes installation is re-encrypted with a random disk encryption key passphrase that isn’t shared until hardware reception and the user booting the hardware, confirms its in a working state and validates that both firmware measurements are as expected and boot components detached signatures are validated per the firmware. Then transfer of ownership happens.

Then and only then, the transitional disk encryption key passphrase is shared so the user can launch the re-ownership wizard to re-own the TPM, USB security dongle and generate his own GPG keypair and re-encrypt Qubes installation with his own secrets. After that point, the ownership is transferred and the warranty on the parts is not covered by the shipping insurances anymore. You already accepted the state of the hardware, where shipping back becomes more complicated and fees are involved.

It doesn’t make any sense for me nor users to diversify the offer, even less without disk nor without Heads.

I think the website is pretty clear on the processes involved and the added value I provide. Without those components, what someone wants is flashing as a service, which would not make sense to me.

Hope that clarifies things a little more.

And sorry for my english, sometimes I seem to not be as clear as I think I am.

2 Likes
5

Just there resides the need for clarificarions.

libreboot IS a coreboot distribution. Limited to support models not requiring blobs to boot, and applying additional logic to remove everything not open source from coreboot. That was a political requirement from FSF for RYF certification. This is mostly political.

osboot supports the same boards set then libreboot(and more), since permitting blobs more liberally. Without RYF constraints. This opens to coreboot boards which requires blobs to boot, and includes microcode updates, where FSF RYF prohibits those even if their removal reduces security or functionality. Again this is a political stance.

Then Heads is a linux coreboot payload. Practically, any board supported by coreboot could support Heads. But the extent of blobs present in coreboot nowadays doesn’t guarantee that coreboot is synonym of open source firmware anymore. This is where it gets complicated. And where other posts in this forum (search for mines) cover those distinctions.

So while you are right saying that the PrivacyBeast is a coreboot enabled laptop, you are factually right. But heads is a security oriented coreboot’s payload, where osboot doesn’t have this goal in mind as of today with seabios/grub.

The standard coreboot payloads, including osboot, is seabios coreboot payload as far as I know. There is no present goal of security. There is a goal of relative openness, when compared to their proprietary equivalent.

Coreboot is a tansparent implementation, which boards define if FSP/Agesa binary blobs are required. If graphics and ram is natively initialized or blobs are required to initialize the platform. The platform will define how locked down you are to proprietary blobs and how much coreboot can actually talk to the hardware, after those components have done their opaque mandate. That is a separate issue to ME/CSME/PSP actually powering up your main CPU and how much those can be deactivated/neutered to limit their reach on hardware they can also control without you knowing.

So at the end of the day, what the coreboot (firmware) environment actually controls matter, prior of passing control to the payload (bootloader) which then passes control to your OS. This is a chain of trust, where Heads idiom is that everything should be taking control by open/native functions/open drivers where possible, but where platforms differs in openness and auditability.

osboot bridges the gap into providing firmware images for less open platforms then libreboot could, where Heads takes a subset of what osboot supports to implement measured boot from the lowest coreboot stage possible to measure the chain if trust and attest to the user its state at each boot, where osboot/libreboot doesn’t aim to do that.

osboot aims to provide the bare minimal blobs required to pass control to coreboot’s payload. And a buidsystem. And some additional tools, like hardware PHY mac generation and a lot of other tweaks and contributions aiming to ease coreboot and free software accessibility. But security is not a goal. Free software is.

Again hoping that this clears things out a little bit more. libreboot osboot heads skulls are all coreboot derivatives. They all have different goals. And that is their goals that should be talked about and investigated.

2 Likes
6

…and it seems that @Insurgo found you too! :laughing:

In addition to was @renehoj has said in response, I offer you this:

Not at all. @Insurgo is telling you that if you remove certain hardware, then your machine will just be a blank slate, with no way to verify whether someone has tampered with it, because the hardware “won’t remember the tamper”, or be able to show you what it used to look like so you can compare it yourself…

The reason they’re removing hardware is similar to a past requirement of some countries’ Antarctic workers to have their appendix removed before departure to Antarctica.

It might not be causing you trouble most of the time, but if there is a time in the future where it does, you couldn’t really be operated on in Antarctica. So the mere fact that it’s there is something that could cause problems.

I apologise for the grusome analogy, but it makes the point quite clearly.

If you have a piece of hardware (set of speakers, microphone, camera, SATA cable :face_with_open_eyes_and_hand_over_mouth:) that are still connected, then there is potential for them to be misused if someone knows what they’re doing.

In Qubes OS, the “security” (if you want to call it that) is in the fact that as many hardware components go into their own separate virtual compartments (called “Qubes”) as early into the boot process as the machine will allow.

This means that any “shenanigans” involving those hardware components are mitigated by the fact that:

  • Anything “nasty” inside one hardware component shouldn’t be able to make it’s way to the rest of the machine
  • The rest of the hardware components shouldn’t even know that each other even exist (Qubes OS gives them “dummy” devices to interact with inside the Qubes), which should eliminate the potential for “creative” hacks to be performed, such as:
    • Using internal speakers as a low-frequency radio transmitter, or
    • Converting internal speakers into a microphone
    • Manipulating colour settings, screen brightness/resolution to exfiltrate data from a machine
    • Hijacking USB firmware to change the voltage to “fry” connected devices
    • Anything else like this

What is the bare minimum hardware you need to run Qubes OS?

  • CPU (obviously, but I have to state the bleeding obvious…)
  • RAM (I mean, you could technically use swapspace, but it would be really slow…)
  • Storage (Where else will Qubes OS go…?)

What else is a “good idea” to have?

  • A screen (it’s not compulsory, but it’s nice to be able to see what you’re doing…)
  • An input device (so you can actually get past the login screens)
    • Keyboard
    • Mouse

Everything else is technically optional, but if you include them, Qubes OS has “things” built into it to mitigate each hardware component that might get “compromised”.

But, if they’re not in your machine…

image
image700×700 57.1 KB

…then they can’t get compromised :sunglasses:

I hope this makes sense :slight_smile:

4 Likes
7

@alzer89 Really appreciate your way of thinking out of the box with examples you provide. This is exactly the kind of mind needed to get things through outside of being lost in the details. Thank you for that, inspiring.

1 Like