Secure boot doesn't disable installing APTs, it disables installing kernel modules.
If you want to disable apts etc, you need SELinux or AppArmor or equivalent.
Secure boot, as the name suggests, secures initial loading of the most central/core parts of an operating system: (indeed) the kernel and kernel modules.
While APTs can be installed on different levels, anywhere from kernel up to user space, a good (hard to detect) place for those is inside the kernel itself or in a kernel module.
Secure boot is definitely intended to prevent APTs, even if its only a part of the the full equation. You still need additional tools on top of a kernel, e.g. SELinux or AppArmor, that monitor, audit and (hopefully) prevent the introduction of APTs. However, without a trusted kernel (and kernel modules), all of those tools can be compromised/circumvented, making it ultimately an impossible task to secure the system as a whole.
Still, "installing APTs" as a synonym for installing packages with apt? I guess I would have noticed it, if it had been "installing DEBs".
Also, using SELinux or AppArmor to disable the ability to install packages with apt is a new thing to me. But I have to admit that I'm not an expert at either.
> ACPI defines many tables that provide the interface between an ACPI-compliant operating system, and system firmware. This includes Differentiated System Description Table (DSDT), Secondary System Description Table (SSDT), and Static Resource Affinity Table (SRAT), for example.
And nothing to do with Debian package management that had the command and file type of “apt”.
I say that it takes this much effort to bypass it shows the opposite: that it does work, it does increase security.
Because without it, you’d be compromised already at step zero.
But like every security measure so far, it’s seemingly not perfect. Nobody is honestly surprised by that, are they?
Also the whole scheme is not better than making boot configuration read only with a hardware switch, or storing your bootloader and /boot on a read-only medium, assuming you are using full-disk encryption.
The issue that I have heard people bring up is that it could potentially make it harder to install free and open source operating systems and thus turn consumer-grade and relatively cheap computers into less of a tool that you can use the way you want and more into an appliance.
For all the panic that ensued when stuff like secure boot and similar were first announced, and the fact that I still seem able to install my Linux distro of choice, I as somebody who has not gotten personally invested in this am not in a position to know how real such an issue is.
But I would like to know what proponents of secure boot think the technology solves and why what we had before inadequately addressed security needs. Because it seems to me that e.g. Windows will still happily get infected with viruses such that whether the boot process itself has been compromised, or just what comes immediately thereafter, does not matter too much. Or does it?
You can detect the existence of a rootkit by booting from known-clean read-only media and then scanning for it. It's even possible to implement "secure boot" this way without any hardware support -- have known-clean read-only boot media that contains your signing keys and then verifies and boots the operating system of your choice.
Implementing this in rushed closed-source system firmware is then purely a misfeature, along with the legitimate concern that it could lead to systems where the device owner can't install their own signing keys. Give people a USB stick with a hardware write protect switch, not signing keys hard-coded in firmware.
And you already need to be able to at least detect that someone has had physical access, otherwise you can't even be sure that the device hasn't been replaced with a compromised one that forwards your credentials to the attacker.