[sterlind]

I think anyone can set it up, it's a feature you can administer through group policy. Actually the entire chain of boot from the firmware to the kernel and all userspace is verified. EFI is verified by Secure Boot (through the TPM), which only runs signed kernels, which only runs signed drivers and signed kernel32/user32/etc. So during a normal boot, all running code has been signed and verified.

If that group policy setting I mentioned is enabled, then running unsigned code will either (depending on the setting) write a security event to the system log, which is uploaded and causes a sev-2, or (if set to strict) simply blocked, with a "Windows has protected your computer" message.

It's definitely available publicly - I've personally imaged servers with stock Windows Server 2019 and slipstreamed our internal monitoring agent (which doesn't do anything magic, it just watched the Windows Security ETW log), and personally gotten sev-2s when I tried running unsigned code.

Hence I really wonder why Linux doesn't do this.. I thought SELinux or something might; it could make things slower but my system runs quite fast so I suspect they keep a volatile cache of verified SHAs.

(Also I should mention that even assembly references are signed, so unsigned assemblies refuse to load.)

[p_l]

There's IMA subsystem that generally does the same, providing verification for executables at least ones that are linked and loaded normally - for obvious reasons it can't exactly fix cases where you have a signed binary that loads unsigned code into itself.

The system supports integration with TPM-stored keys, so you can bind to kernel verification or the whole firmware chain of trust (a question of which PCRs you end up using to bind the keys).

Unfortunately, it's not well known (especially if you don't compile your own kernel reading through all the options), and generally, not many distributions look into providing it - plus everything involving SecureBoot and TPM has to deal with poisoned opinions in open source community.

[mdip]

Thanks for the reply -- I guess what I'm wondering is how can reliably alert about execution of unsigned code on a system that cannot prevent the kernel/OS/firmware from being replaced by something evil. Based on your reply, it sounds like that's a pre-requisite[0], otherwise evil-kernel could simply report that signatures are passing for everything under its control.

I can think of several (imperfect) approaches for protecting a system that meets those per-requisites but is incapable of, say, validating userland programs -- though even that would be tricky to do reliably unless the kernel is checking signatures on execution, rather than passively (via filesystem checks, etc). This is more a fault of any system that "alerts when something out-of-policy happens" vs "prevents something out-of-policy from happening"

The part I have a difficult wrapping my brain around is what kind of system exists with those limitations? If the system is capable of verifying that it is running a signed firmware, bootloader and kernel (along with any other components that are doing signature verification), why isn't that same system capable of preventing every unsigned application from running, eliminating the need to issue a sev-2 for the impossible situation of "it's running unsigned code unexpectedly". The two major examples that come to mind -- Windows and Linux -- handle both requirements (albiet, with additional software on the Linux side/additional configuration on the Windows side).

Recent Windows versions do not have this limitation, AFAIK. Intellicode/code signing has been included for quite some time. It's mature, a lot of it is enabled by default with balanced default settings and as you mentioned, it's not terribly difficult to set up a system to be very strict with its handling of signed code execution[1]. I should clarify -- despite my last comment -- that I believe the way Microsoft implemented this to be well thought out. Though my Dad[2] will probably always click through the SmartScreen message, no matter how ugly it looks, and it can certainly offer a false sense of security for those who leave it in that default configuration, it still adds a nice layer to the onion (without being obnoxious) and serves as a foundation/required component to enable strict policies[3]. And I prefer this approach to a more strict "walled garden" approach -- freedom/usefulness has a security cost[4].

On the Linux side, depending on the distribution, this may or may not be available "out of the box". I know the distribution I run -- openSUSE Tumbleweed -- enforcing bootloader/kernel signing and enabling trusted boot is straight forward (simple if your hardware is natively handled by everything out-of-the-box, but still relatively easy if you have to compile in a module, AFAIK -- having never gone through the pain, myself). And there are a few options after that for userland that are comprehensive in that the aim isn't just to cover elf executables but to ensure that the important parts of the system are cryptographically verified to be unaltered[5].

[0] Assuming the kernel handles signature verification, or minimally verifies the signature of whatever does handle that.

[1] PowerShell is a great example; though it frustrates the hell out of people (me, and anecdotally, everyone I've worked with immediately after trying to run their first script on a new OS load), I love that the default configuration is (maybe was?) "Signed Only", requiring a bit of work (far less in the last version of Windows 10 that I used) to allow unsigned script execution, paired with a permissions system that lets administrators prevent lower security accounts from altering that setting (which also defaults/might only be allowed to be set by administrators in the first place).

[2] Not picking on him -- he was a heck of a power user back in the day, but thinking the average Joe/Jane who re-uses a handful of passwords (just got the parents out of this habit) and are otherwise oblivious to security warnings.

[3] In some ways, it's an extension of the GPO executable white-list -- which was easily bypassed by renaming evil-executable.exe to something that is allowed. Now, contents are checked and the white-lists are tiered (i.e. video/sound drivers must be signed by the user and an MS certificate, which doesn't happen until the program is evaluated ... IIRC, of course).

[4] A computer that's melted down into a mass of plastic/metal hack-proof,... and use-proof. Less snarky -- a computer that has no hardware capable of allowing it to communicate on a network is going to be many orders of magnitude more difficult to breach by simply following good practices on the physical-security front, but it'll be similarly useless if that system was intended to host a publicly accessible web site.

[5] As was mentioned, before, even saying "ensure all executable code is signed" isn't enough for some environments -- ensuring configuration is unaltered is an obvious one. Even signing state data is necessary in some cases, i.e. a system is hibernated, drive is removed/file is altered, and the system is booted, loading evil-hiberfile.sys. Sheesh, security work is fun -- close one hole and the "what abouts" start popping up everywhere else.