It's why operating systems should implement a lockdown option to restrict users from performing arbitrary access to memory or kernel, even if the user is root. I mentioned before that, on one of my computer, I completely disabled dynamic kernel modules, hotpatching, /dev/mem, no ptrace() to arbitrary process, etc., making it difficult for root to do any low-level access to memory or kernel. I also enabled IOMMU, it isolates the address spaces of different hardware from each other, so no external hardware cannot have arbitrary RAM access via DMA, hardware-based memory capturer won't work. The only way to attack is either an 0day or a cold-boot attack, the 0day threat can be reduced by using a security-minded kernel, like PaX/grsec (not available to the public anymore), OpenBSD, or HardenedBSD. As for cold-boot attack, future hardware may support full memory encryption [0] at the hardware level and fix this vulnerability. Mouse jiggler is a problem, but USB firewalls already exist [1], if proper policies is enforced by the firewall, unauthorized hardware cannot register as an input device.
There may be still some exploits, especially when you consider that Linux kernel is not designed with security as its first priority, and over the last 20 years a lot of black magic has been developed to insert bad things into the kernel, but at least doing the countermeasures I mentioned will make it difficult. Hence, it's impossible to do any low-level changing or debugging on the system without rebooting it - which will immediately revert the system back to a "at rest" state, and triggers full-disk encryption. Other people may choose to do the opposite, it's a tradeoff between uptime and security.
Unfortunately, any attempt to introduce such a lockdown will be accused of being an evil technology that enables DRM. However, ultimately, the question is not whether a computer is locked down, but who is in control of the computer and it's locked down to protect whom.
[0] Don't confuse "memory scrambling" and "memory encryption". The vast majority of PCs today already use memory scrambling - the memory controller will "scramble" the data in RAM to a seemingly-random pattern using a Linear Feedback Shift Register, but it's done for electrical considerations - if there are too many 1s or 0s in a row, excessive current spike (di/dt) is produced, and it reduces signal integrity and creating excessive electromagnetic interference - LFSR-based scrambling is not for cryptography purposes and trivial to decode. On the other hand, memory encryption is a true solution that provides cryptographic protection to the RAM, and many hardware vendors have roadmap to implement it. Currently, it seems that there are two types, the first type is a "full memory encryption" - protecting RAM from physical access, the second type is "per-application memory encryption", which allows an application to request a segment of encrypted memory with an unique key - protect sensitive data of one application from accidental access by other programs. Both are helpful.
Just a note for you (and other readers), as I think it needs some elaboration.
> no ptrace() to arbitrary process
Traditionally, ptrace() restriction is a grsec feature. But in mainline kernels, the same feature is available in the Yama module, see [0]. Use Yama with "kernel.yama.ptrace_scope = 3" will permanently disable ptrace() for all users, including root, and it cannot be enabled again. Then, you should also compile your own kernel, so you can disable /dev/kmem (CONFIG_DEVKMEM), /dev/mem (CONFIG_DEVMEM) and /proc/kcore (CONFIG_PROC_KCORE) in the Linux kernel. Also, I forgot to mention kexec(), which allows the attacker to execute another kernel without rebooting, so CONFIG_KEXEC should be disabled as well. And the list goes on and on, I think it's necessary to download an old grsec kernel, and using the configuration section of grsec as a checklist (and try disabling them using mainline technique if possible) if your security is serious business.
If you do these things, it will block the technique described in the original article.
