[fsflover]

> the attacker takes the harddisk from your laptop while you aren't watching

> You'll never notice they did that.

Won't you be safe if you put a colorful nail polish to your laptop screws and take picture of its pattern? Then you regularly compare the actual pattern with your picture.

[ruthmarx]

No. Anyone trying to tamper with your laptop that had that would do the same as you and take a photo to restore.

[fsflover]

It's practically impossible to repeat a pattern with tiny colorful particles.

[ruthmarx]

I realize now you are talking about using the nail polish to detect if a screw has been removed as opposed to checking if the screws had been taken out and put back in a different order.

In that case, I would say 1) Nowadays with high res photos and various types of printers, I do think a pattern could be printed back onto a screw head, 2) there is no way you would be checking this every time the laptop was out of your site, let alone reapplying the polish, 3) there are numerous significantly simpler methods that achieve a better result.

[fsflover]

> I do think a pattern could be printed back onto a screw head

I've never seen anything like that and don't believe it's practical. 3D-printed patterns will not look the same.

> there is no way you would be checking this every time

This entirely depends on your threat model and how much you suspect a tampering at specific conditions. In principle, you could even (automatically?) take a picture of all screws regularly and compare it with the original using some other, trusted device. In the worst case, you will find out about the tampering later, but it's a very different case than not knowing at all, forever.

> there are numerous significantly simpler methods that achieve a better result

What is simpler depends on the threat model and a person. But I don't disagree. For me, Secureboot is not a better method anyway.

[ruthmarx]

> I've never seen anything like that and don't believe it's practical. 3D-printed patterns will not look the same.

I'm not talking about 3d printers specifically, just high precision printers. It's absolutely practical.

> This entirely depends on your threat model and how much you suspect a tampering at specific conditions.

I was talking about you personally, who I assume is a pretty average developer that doesn't have state actors after them.

> What is simpler depends on the threat model and a person.

No, it doesn't. This screws method you describe is inferior for all threat models and persons. It's basically security theater.

> For me, Secureboot is not a better method anyway.

You might not prefer it, but it is objectively a superior method.

[fsflover]

> just high precision printers

2D printers just won't cut it: https://i.pinimg.com/originals/90/7a/2e/907a2ece23d412d28b66...

https://3.bp.blogspot.com/_BkvigWu1n1A/S8YrMyV_kTI/AAAAAAAAB...

(and so on)

> I was talking about you personally, who I assume is a pretty average developer that doesn't have state actors after them.

This is why I wrote below about eventual discovery of a possible tampering and low priority of checking it in principle.

> This screws method you describe is inferior for all threat models and persons. It's basically security theater.

This is a strong claim without any evidence. You didn't show how to overcome it.

> You might not prefer it, but it is objectively a superior method.

It isn't: https://forum.qubes-os.org/t/discussion-on-purism/2627/187, and https://forum.qubes-os.org/t/discussion-on-purism/2627/158, and https://news.ycombinator.com/item?id=41072929, and https://news.ycombinator.com/item?id=41071708, and https://news.ycombinator.com/item?id=35843566

[jest3r1337]

I have a laptop with a soldered in disk! Check mate mofo! All for our safety of course!

[patrakov]

Hello, this is a security auditor. Could you please confirm items on the following checklist?

1. A BIOS password exists, with at least 8 characters, not based on a single dictionary word or keyboard-run sequence, and not easily guessable in other ways.

2. Booting an OS from any non-default device requires entering the BIOS password.

3. GRUB entry for bringing up the firmware configuration does not bypass the password.

4. GRUB itself has a password defined, with similar password strength requirements.

5. Editing the kernel command line or accessing the raw GRUB command prompt requires the password and, likewise, cannot be used to boot kernel/initrd pairs from external media.

[gradschool]

I don't trust bios passwords. There's probably some jumper on the board that bypasses them or a previously planted hardware keylogger. I always boot off separately stored immutable rescue media whenever the machine has been out of my custody and checksum the whole boot device. Your move.

[patrakov]

Sorry, this is not a valid answer - you can checksum the boot device as much as you like, but I have not seen any procedure that ensures that you know the correct checksum. What could have helped you is not just a checksum, but a signature used with dm-verity.

What I do on my laptop is:

* BIOS password, of course. Note that this also prevents the attacker from resetting or turning off Secure Boot.

* Secure Boot enabled, with my keys only (no Microsoft keys).

* No GRUB, I use systemd-boot (part of systemd) and UKIs signed with my own key. Although, as I don't dual-boot, this might be an unneeded step. In any case, with Secure Boot enabled, systemd-boot does not allow editing kernel command line arguments at all and so cannot trick my UKI into doing anything else than what it is supposed to do.

* The main SSD partition is encrypted (with the passphrase that I have to type).

* The USB storage driver is not in the initramfs, so the storage device found by the initramfs is guaranteed to be my internal SSD.

* The Secure Boot keys are stored inside that encrypted partition and are used to dynamically sign new sd-boot releases and UKIs. I guarantee that I don't sign anything except UKIs that ask for my SSD password, and any shell-out possibility is treated as a bug.

* There is a separate set of keys for signing the custom rescue media, which is also a big UKI.

This way, the attacker cannot boot anything other than my UKI (first, because of the BIOS password, and second, because Secure Boot won't allow anything else), cannot obtain a shell by running something before I enter the password, and, therefore, cannot clone or overwrite my disk.

Note that this setup has also been criticized as insecure ("you don't use TPM, so you can't be secure, it's a theorem"), but I don't understand this argument.

As for the hardware keyloggers, you are, of course, right.

[NekkoDroid]

> * The USB storage driver is not in the initramfs, so the storage device found by the initramfs is guaranteed to be my internal SSD.

Do note, if you are using systemd-gpt-auto-generator with the DPS[1] it only searches for a root partition on the drive with the booted from kernel[2] (and any other DPS partitions are searched for from the drive with the root partition, so if you somehow specify a different drive than the one with the boot loader it will search on that different drive)

[1] https://uapi-group.org/specifications/specs/discoverable_par...

[2] https://www.freedesktop.org/software/systemd/man/latest/syst...

[lofaszvanitt]

:DDD And you gonna check it every time? Nah, humans are not wired to this.

[fsflover]

Yes, if I expect such an expensive, targeted attack on me. This is a Snowden's case, not for normal folk.

[lofaszvanitt]

And that is 1 user in a million. So we force people to do everyday things in a bulletproof vest, because of that 1:1000000 use case?

[fsflover]

If you don't expect such an attack, then with your threat model you don't need to do that.