I want something different to Librem Key where the anti-tamper detection software only runs on the OS.
Just curious is there an anti-tamper detection software which detects if GNU/Linux has been tampered with, for example if somebody else used a live USB stick and booted their operating system on a computer and tampered with any of the system files or something?
I would guess that tamper detection software that only runs on the OS can’t reliably detect tampering with the OS. (In other words, I can tamper with system files and then tamper with the tamper detection software so that the tamper detection software is blind to my tampering with system files and blind to my tampering with itself.)
There is a distinct advantage in having the tamper detection run independently of the OS.
Ok so I have a home partition that is encrypted, what if the executable and its config files or whatever are stored in the home partition, that way when I decrypt the home partition, I can then check if something was modified or something, is there such a software mate?
You would need to make sure that the executable does not rely on any shared libraries that are located outside of /home.
Even then the executable will rely on core operating system functionality (e.g. to read files / blocks of the root file system / partition or e.g. to obtain the password needed to decrypt /home after which all bets are off) and that functionality may have been tampered with.
The only way that I can see this working is:
boot the computer from a removable disk (such as a flash drive) that contains either a live boot of an operating system or a normally bootable operating system, where the removable disk remains in your custody at all times and hence can’t be tampered with, and then
use commands or scripts run on that boot to verify the installation on the main disk
This would be slow and inconvenient. So you wouldn’t want to have to do it too often - and if the slowness or the inconvenience of it discourages you from doing it then that in itself is a security weakness.
The other way is to have a secure boot path i.e. BIOS itself can verify the first stage boot and each stage of boot can verify the next stage boot before transferring control. However that isn’t exactly the Linux way because some Linux users like to make their own operating system builds, completely replace the existing operating system with a different operating system, etc. etc.
Some users like to set a BIOS password so that a would-be tamperer can’t boot from an external drive or otherwise mess with things unless you supply that password. However that doesn’t work if the BIOS has a backdoor, password or otherwise; and in any case it only partially solves the problem because a determined tamperer can remove the internal disk, install it in a different computer, tamper with it, and then reinstall it in the original computer.
Not really. That would require that you modify the firmware of the USB drive - and have sufficient expertise in writing firmware for embedded microprocessors - and start with a platform that even allows this and has sufficient documentation to complete the job. (The point is that the key is more than just storing information, it is executing code that is capable of detecting tampering.)
Practically speaking, you would be reinventing the wheel. If you want to learn stuff then that is fine. If you just want a secure (untampered with) system now then buy something that already does the job.
librem key detects tampering with your boot vector. It does not protect against OS tampering. For that there are tools like tripwire (which has open-source version) which checksum all critical OS elements (and whatever you tell it to) so that later you can check if anything has changed.
Similarly as with boot-vector protection you’d need to maintain your trusted state - after each trusted update re-checksum the OS. Apparently since tripwire is software-only solution you’d need to make sure your trusted state (chesksum db) is stored securely either offline (eg usb dongle) or at least in encrypted storage.
No, not on shutdown, at any time you think you can trust your system (eg immediately after system upgrade or package update). Mind you may be having rootkit deployed remotely via zero-day exploit which will tamper your system even while you are working on it. So on a consequent check tripwire will detect OS tampering and raise a high alert.
But if you trust your firewall you can of course hook it up to the shutdown/startup sequence to re-checksum on stop and verify on start. although that would protect only against offline/side attack vector - as you’ve mentioned to either boot from another device or attach+mount your drive to another device. It won’t protect if someone actually managed to boot into your system (or misuse while left unattended).
Oh sorry I poorly explained what I meant. I meant like upon shutdown would it generate a hash based on the root area and then store it on the home partition (as the home partition is encrypted but not the root partition) and then if I were to boot into the OS, after providing the password to decrypt the home parition, tripwire would then perform a checksum and match the generated hash with the one that is stored on the home partition?
I am not too concerned about viruses or malware as I would know how to ensure this does not happen. BUt I am more concerned about if my PC was off and somebody tampered with the system.
still I would rather recommend not to bind hashing to shutdown. Even without shutdown your system may and should only be changed under your control (update, upgrade, explicit modification). So after such conscious modification just make a snap and then do checks against it periodically. Doing it during the boot is of course necessary (early detection), but not sufficient (don’t disregard periodic checks).
And rootkit is not a virus or malware, it’s “your system is being pwned”. So it is the highest state of tampering (remote control).
This is right on and exactly the reason why we start tamper detection where we do in the boot firmware, the first software that the device runs. Without starting there, an attacker can tamper with the very systems you would be asking later to detect the tampering and be able to cover their tracks. The idea is you trust one level, then use the trust in that level to trust the next level in the boot process, and continue to extend that as many levels as you want to go. Currently we only extend from the boot firmware all the way down into the files in /boot (kernel, initrd, grub configs).
This is how we currently anchor trust with PureBoot, along with what is trusted:
System sends boot firmware (coreboot + Heads) measurements to TPM, if they match known good measurements, TPM unlocks a secret, converts it to 6-digit HOTP code and sends over USB to Librem Key. If the code matches what the Librem Key itself generated, Librem Key blinks green. This process proves to the user that they can trust the contents of the boot firmware, which includes a custom GPG keyring containing the user’s public key.
Since we can trust the firmware now, we can trust the GPG keyring in that firmware. Heads then uses the GPG keyring to verify the signatures of all of the files in /boot to make sure they haven’t been tampered with. If they haven’t, it will then execute the kernel and boot into the OS.
So with this process, we currently bootstrap trust as far down as the files in /boot. This protects you against kernel rootkits but nothing below that (trojaned /bin/bash for instance).
I have been working on something to allow us to go a step further, and have a basic proof of concept written, that would take the form of a script that runs inside the initrd. Once / is mounted but before the kernel pivot_roots into it, the script in the initrd would then check GPG signatures against the files in /etc /lib /bin /sbin and optionally /usr as well. In tests I’ve done this adds an extra minute or so to the boot process if you include /usr as there are a lot of files to check. But this would protect you against attacks that would modify standard system libraries or binaries (and allow you to extend it further into other parts of the file system if you wanted). Of course you also have to go to the trouble of re-signing files in these directories whenever you perform a system update.
The chain of trust then would look something like: