[PLUG] Fwd: Linux Install & school

Whoops; meant this as a list reply; not direct. Sorry about that; mobile clients are not great for mailing lists, still, in 2024.

---------- Forwarded message ---------
From: brent saner <brent.saner@gmail.com>
Date: Wed, Jan 10, 2024, 05:18
Subject: Re: [PLUG] Linux Install & school
To: Rich Freeman <r-plug@thefreemanclan.net>

On Tue, Jan 9, 2024, 15:37 Rich Freeman via plug <plug@lists.phillylinux.org> wrote:

On Tue, Jan 9, 2024 at 3:04 PM Aaron Mulder via plug
<plug@lists.phillylinux.org> wrote:
>
> (even if we selected Windows from the Grub menu, Windows wanted a BitLocker recovery key because it noticed the changes, and we don’t have that for the school machine).

Well, Windows didn't notice the change so much as the TPM did.

Nope. bcfg and BitLocker lock for many reasons. This sounds more like a Bitlocker *recovery*, which doesn't involve TPM at all.[0] (Addendum: Bitlocker recovery is like a "soft lock"; it can be removed by simply restoring the flagging condition state, such as by moving the disk's boot order to the first entry again.)

Most
likely it is configured to do a measured boot, so when the firmware
booted grub it hashed the grub EFI program and loaded that into the
write-once-per-reset TPM memory before executing grub. Then when
Bitlocker went to retrieve the key for the hard drive encryption the
TPM noted that the boot history had changed and refused to provide the
key. The recovery key would provide an alternate means of access -
without one or the other there is no way to decrypt the hard drive.

Last I checked, Measured Boot, if enabled for an org in Windows 10 and up, uses remote attestation and requires third-party client to request attestation.[1] It is unlikely this is enabled on a laptop issued by an org does not take the basic attention to lock out external/removable boot entries. School IT dep'ts are notoriously minimum/superficial effort.

> I think the problem there is that the Ubuntu install changed the UEFI setup to put Grub higher in boot priority than Windows. Though I’m not sure, I don’t think it removed or corrupted the Windows boot loader, I think it just set Grub to be a higher priority. We couldn’t set it back because the UEFI menu is password-protected. Why could the Ubuntu installer change the boot priority but we need a password to change it back?

I'm not super-familiar with the EFI APIs/etc, but those might not
require a password. That suggests that an appropriate tool could edit
your EFI settings.

Yes.

Note that they need to be completely restored so
that the device firmware runs the same EFI executable that it did
before Ubuntu was installed, and not some kind of shim-loader.

Unlikely; see above.

. This is a pretty typical
secure configuration on laptops - at least the ones that don't run
Linux other than ChromeOS.

Typical for orgs that lock down beyond "UEFI menu has password, is gud", sure. Typical for school-issued hardware? Absolutely not.

[0] https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/faq#what-causes-bitlocker-to-start-into-recovery-mode-when-attempting-to-start-the-operating-system-drive

[1] Checked. Yep.

https://learn.microsoft.com/en-us/windows/security/operating-system-security/system-security/secure-the-windows-10-boot-process#measured-boot

*Could* they be using one with a local cache? Sure. Is it contextually the most likely? Nope. Occam's and zebras.