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.
How would the librem key work then? Would it automate all of the verification stuff?
Do you know anything else that would make it all automated and the software itself can’t be tampered with?
I could have another encrypted partition and if I manually decrypt the partition through that I can then run a program that detects for unauthorised tampering?
I see now, is it possible to make my own librem key through a USB drive?
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.
Interesting. I think I would like to have a look at tripwire. So does it automatically perform a checksum upon shutdown and just before I boot into the OS?
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:
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:
You could then extend that further by putting a script in /bin /sbin or /usr that verifies other directories after you boot, if you wanted.
You could use something like AIDE (Advanced Intrusion Detection Environment) or tripwire in conjunction with PureBoot to check additional directories and files post-boot.
See here:
Not sure if they have it in their repositories for PureOS, but should be able to get it without too much trouble.
hi there! 
my approach is to make two stages of the boot process
the layout is like this:
unencrypted /boot/efi
luks encrypted /boot with the luks header for the rest of the system
dm-crypt for the rest, with btrfs to make the sys more granulated, like for a compressed /home
the 1st stage is to unlock /boot from /boot/efi, and then i can see if its my composition there, as it can only be changed entirely, and i can make there any kinda magic to make it hard to copy its interface (style+whatever hard to figure out generated code to display). then check if the /boot/efi is intact, and then i can enter the pw for the dm-crypt’d part with all of my treasures.
actually it wont protect against firmware hacking, but i could lock the house with whatever sticker that will be destroyed in case of messing with it, and also, it wont protect against entering from the sw side, but thats an another thing…
(btw it is under construction at the moment, with a custom one-time-effort void linux installer that will make everything i need on a fresh system 
(ok, 2 times, im writing it in bash, but i plan to write it later in lua with more flexibility and automagic, as i orient there everything, but now i just want to make it ready sooner than later, and all the resources are in bash…))
all the bests to all of u!
btw git head of grub now supports luks2