Add way to configure from a rich OS

[Jookia]

Currently the only way to configure the shim is through its console, before the OS has booted.
This is unfortunate for headless setups and people that require assistive technologies to use their computers.
Having a way to view logs, errors messages and manages keys from a rich OS would be very helpful.

This is a clarification of #391 which was wrongly closed.

[julian-klode]

You really need to start using the correct words if you want people to understand you. Shim is not configurable during boot.

Keys are managed from the OS usually by mokutil setting them up and then you have to confirm them during boot in MokManager. There's no way to launch MokManager without an OS or EFI shell instructing shim to load it.

There's also no way to load keys directly without confirming them in MokManager, because that would break the security model.

Logs are only printed to the console, so not readable past Boot, and hard to catch at boot.

[julian-klode]

Sorry, I hit the button by accident.

So as I said before, it seems reasonable for me to be able to dump logs into a runtime variable such that you can read them after boot and share them; and don't need to record your screen with a camera during boot.

[Jookia]

You really need to start using the correct words if you want people to understand you. Shim is not configurable during boot.

My previous bug was 'way to use', but it got closed so I tried 'configure' and I guess I got it wrong. My bad.

There's also no way to load keys directly without confirming them in MokManager, because that would break the security model.

My request then is to have an easier way to confirm them that doesn't exclude people with disabilities.

[Jookia]

In the closed issue you said:

That's the basic security model, and not a bug.

Does this mean shim is inherently off limits to people who use assistive technologies?

[julian-klode]

Assistive technology is up to your UEFI vendor to provide I'd say.

[Jookia]

How does shim interact with the UEFI assistive technology APIs then?

[julian-klode]

mokmanager does not do any drawing, it just calls console_errorbox and other console_print_box_at() and similar to print stuff. So I don't see why it'd be less accessible than any other BIOS component.

I'm not aware of any specific UEFI assistive technology APIs, do they exist? I don't think UEFI even has sound support.

[Jookia]

Shim does its own drawing. console_errorbox and console_print_box_at are defined in lib/console.c .
I'm not aware of them either, but I thought your statement on how it's the vendor's problem implied this was solved.
How can a vendor provide assistive technology if there's no APIs then?

[Jookia]

I do want to add that putting assistive technology in UEFI would be a TERRIBLE, TERRIBLE idea given its complexity and obscure software and drivers.

[julian-klode]

OK ok, I missed that. But without assistive technology in UEFI, you won't get accessible MokManager. So you won't be able to manage MOK keys if you can't read a screen. But then you also can't configure UEFI secure boot or any other BIOS setting either.

Having to confirm the key changes during boot is essential to the security model of shim, otherwise the OS could just install whatever keys it wanted to rootkit you. shim's security model is that someone physically present must confirm the key changes during boot.

[Jookia]

But then you also can't configure UEFI secure boot or any other BIOS setting either.

This is what makes the problem a lot worse. A lot of disabled people are forced by motherboard vendors to use shim to boot Linux and can't configure it.

Having to confirm the key changes during boot is essential to the security model of shim, otherwise the OS could just install whatever keys it wanted to rootkit you. shim's security model is that someone physically present must confirm the key changes during boot.

Okay, but with the state of technology this isn't useful for people with disabilities. So it needs to change to include something like a trusted rich OS that can boot specifically to provide a consent menu.

[steve-mcintyre]

But then you also can't configure UEFI secure boot or any other BIOS setting either.

This is what makes the problem a lot worse. A lot of disabled people are forced by motherboard vendors to use shim to boot Linux and can't configure it.

The vast majority of shim users never have to configure anything, though?

[julian-klode]

Only people who use custom kernels or custom kernel modules ever need to interact with shim/mokutil/MOkManager. Like people using Nvidia.

I don't see how you'd build an OS trustworthy enough to run all this before ExitBootServices(), and I don't see how you could proof to MokManager that your OS was not compromised when you go via runtime variables. Like you'd have to sign a variable with something that's sealed by the TPM such that it only unlocks if you are not compromised or stuff. Like shim would have to generate a public/private key pair, store the public key in the TPM, seal it with the measurements of the binary, and then offer it up to the booted MokManager OS if not compromised? It seems a tough thing to do.

[Jookia]

The vast majority of shim users never have to configure anything, though?
Only people who use custom kernels or custom kernel modules ever need to interact with shim/mokutil/MOkManager. Like people using Nvidia.

I'm not sure what the point is here. That accessibility is proportional to how often people use the feature? That people shouldn't do things that require using MokManager in the first place? If so, why's it there?

I don't see how you'd build an OS trustworthy enough to run all this before ExitBootServices(), and I don't see how you could proof to MokManager that your OS was not compromised when you go via runtime variables. Like you'd have to sign a variable with something that's sealed by the TPM such that it only unlocks if you are not compromised or stuff. Like shim would have to generate a public/private key pair, store the public key in the TPM, seal it with the measurements of the binary, and then offer it up to the booted MokManager OS if not compromised? It seems a tough thing to do.

Well you already trust the existing OS you're using to an extent, otherwise you wouldn't boot it. Having MokManager signal to the OS to boot in to a safe mode of some sort specifically to gather consent could work. If the OS is already compromised, there's bigger problems, no?

An alternate way to go would be to have MokManager open a HTTP server with a display GUI. Maybe using a RTOS and configuration passed from the unsafe world.

[steve-mcintyre]

I don't see how you'd build an OS trustworthy enough to run all this before ExitBootServices(), and I don't see how you could proof to MokManager that your OS was not compromised when you go via runtime variables. Like you'd have to sign a variable with something that's sealed by the TPM such that it only unlocks if you are not compromised or stuff. Like shim would have to generate a public/private key pair, store the public key in the TPM, seal it with the measurements of the binary, and then offer it up to the booted MokManager OS if not compromised? It seems a tough thing to do.

Well you already trust the existing OS you're using to an extent, otherwise you wouldn't boot it. Having MokManager signal to the OS to boot in to a safe mode of some sort specifically to gather consent could work. If the OS is already compromised, there's bigger problems, no?

The whole point of the setup with shim is that you don't trust the OS that's loaded after ExitBootServices(). It might be compromised, but it can't make permanent firmware-level changes. The security model is there for a reason.

[Jookia]

The whole point of the setup with shim is that you don't trust the OS that's loaded after ExitBootServices(). It might be compromised, but it can't make permanent firmware-level changes. The security model is there for a reason.

So maybe the HTTP server would be the best solution.

[TriMoon]

I just stumbled across this issue while randomly browsing...

From what i understand; What the OP actually wants is ability to communicate/interact with shim without the visual on the console because people with certain disabilities won't have access to that visual on the console.
(Think about blind ppl)

So thinking about that, i think the best approach would be usage of a console via a serial port, which could be utilized by special hardware those people already use.
Eg. A switch or option to input/output via a serial port.

Then the special hardware could transform the output on the serial port to fe. braille and select options using braille back to shim's menu logic.

Thus no need for special UEFI variables etc...

• Just output to a serial port instead-of/in-addition-to the visual console.
• Just input from a serial port instead-of/in-addition-to the keyboard.

I think that would be enough to allow ppl with certain disabilities to interact with shim right?

@Jookia So maybe the HTTP server would be the best solution.

I don't think adding a HTTP server in shim is a good idea, imagine the size and headages of such stuff wrt security, when it's much simpler to use a serial port that's only accessible on the hardware self.

[Jookia]

No I specifically mean the ability to configure from the trusted system you've booted.

[julian-klode]

We said before that that does not align with the security model, and the http server opens up a lot of issues (it also breaks the security model, because mok changes require attended boot, not attached via network), so the serial console instead of an http server kind of makes sense.

[frozencemetery]

Hi, this is your local code of conduct enforcer speaking. We strive to create a respectful, empathetic environment for our community. While there will be disagreement around technical issues, it is possible to do this in a way that preserves mutual kindness.

This conversation has drifted beyond what we consider acceptable in the community. Please consider this a warning: everyone is a person deserving of respect, and in this space they will be treated that way. I will be editing the conversation upthread to reflect this.