Re: Regarding securelevel startup window

On 3/18/2026 14:11, Isaac (.ike) Levy wrote:
>> On Mar 11, 2026, at 6:02 PM, Bryan Drewery<[email protected]> wrote:
>>
>> On 3/8/26 1:59 PM, Isaac (.ike) Levy wrote:
>>> Hi All,
>>>
>>> I've been re-reading Design and Implementation cover to cover, been a while, this time as part of a project teaching portable shell programming to some wonderful, burgeoning programmers.
>>>
>>> I've hit a question regarding, the securelevel startup window:
>>>
>>> The system has to boot at securelevel -1 before it can raise. Does anyone know if that window has ever been exploited in the wild?
>> securelevel is a nice thing but it's like locking your front door. It doesn't achieve much against an attacker. The boot issue is a big hole. Simply copying a rogue kernel module to /boot/kernel, modifying kld_list in rc.conf, rebooting, would load that module before securelevel is set. You'd probably never see the file if that happened as it would hide itself after boot. Or just replacing some file in there and rebooting. Or any other rogue script thrown into /etc/rc.d.  If an attacker has root access securelevel does not matter much.
> Thanks Bryan!  That's a very simple and clear illustration of the risk at reboot.  Has had me thinking since you responded.
>
> It has me pondering what fundamental changes could be made to seal this up, but everything I think of so far, more or less just move the problem, or make the system impractically rigid.  I'll likely keep thinking on this...
>
> Best,
> .ike
>
This is the problem that "secure boot" attempts to resolve.

If the loader must be signed (or the EFI bios refuses to load it) and 
said loader then requires all modules to be signed (or it refuses to 
load them), and the signing keys are secure, then replacing a module (or 
the kernel), or adding one that is not signed or signed with a 
non-trusted key pair fails.

However, this is not necessarily good enough because, for example, the 
loader can (theoretically) see any block device and so can the kernel 
once loaded, so if something such as the *keyboard* is compromised the 
boot could be interrupted and at this point the loader has passed 
control and cannot enforce its constraints.

Actually securing the entire boot process in a way that isn't fairly 
easy to break thus requires quite a bit of thought.

-- 
Karl Denninger
[email protected]
/The Market Ticker/
/[S/MIME encrypted email preferred]/