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.

[Jookia]

Most computers lack a serial port.

On Fri, Dec 23, 2022 at 11:07:37AM -0800, Julian Andres Klode wrote:

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.

-- Reply to this email directly or view it on GitHub: https://github.com/rhboot/shim/issues/424#issuecomment-1364240598 You are receiving this because you were mentioned.

Message ID: @.***>

[julian-klode]

I think you will find that most computers come with a universal serial bus.

[Jookia]

On Fri, Dec 23, 2022 at 11:34:41PM -0800, Julian Andres Klode wrote:

I think you will find that most computers come with a universal serial bus.

How do you plan to use this as a serial port?

Most computers cannot act as a B device, and most computers don't support the USB debug interface.

Edit: It's incredibly easy to just rattle off protocols and terms but it needs to actually work or be usable.

Edit 2: Oh, I think you confused serial port with serial bus. These aren't the same thing.

[TriMoon]

@Jookia Most computers lack a serial port.

Not the ones that disabled ppl use, like i mentioned using a braille interface. They either have a computer with serial ports on the motherboard itself, or have placed an add-on card to be able to connect their braille interface to the computer.

Anyhow, any solution that would assist the people with disabilities would still need to be as safe as for those without. Eg. It would still need physical presence near the computer itself, or at least need a physical connection (monitor/keyboard/serial port) but NO-networked connection... Maybe, just maybe an USB connection could be used also, but not sure about that, because that could be network-proxied also if im not mistaken...

But in all fairness, this request is actually something the UEFI should provide as it is related to interaction in the boot phase of the computer itself and not the Operating system. shim is just a middleman used in the phase that transitions from UEFI (BIOS) to Loading the Operating system. So i would, although kinda unwillingly, suggest you to ask the UEFI developers (M$-crapazoids) to add functionality to assist disabled people :vulcan_salute:

All other software that interacts with the UEFI, which shim is also, is bound by the rules they set in their specifications regarding SecureBoot...

[Jookia]

On Sat, Dec 24, 2022 at 01:01:34AM -0800, ©TriMoon™ wrote:

@Jookia Most computers lack a serial port.

Not the ones that disabled ppl use, like i mentioned using a braille interface. They either have a computer with serial ports on the motherboard itself, or have placed an add-on card to be able to connect their braille interface to the computer.

I'd be interested to see the survey you're using for this. Most disabled people don't use a braille interface, most modern braille displays use USB or Bluetooth, and most serial ports for braille displays are USB to RS-232.

Having an actual serial port in your computer is getting exceedingly rare.

Anyhow, any solution that would assist the people with disabilities would still need to be as save as for those without. Eg. It would still need physical presence near the computer itself, or at least need a physical connection (monitor/keyboard/serial port) but NO-networked connection...

I don't think it's fair to rule out a networked connection but still keep in the idea of a serial port. Most Ethernet cards support crossover or you can buy crossover cables which mean you can effectively connect two computers directly together and talk over Ethernet without any router, even on laptops. I don't see why wires from one port are more trustworthy than wires from another port.

But in all fairness, this request is actually something the UEFI should provide as it is related to interaction in the boot phase of the computer itself and not the Operating system. shim is just a middleman used in the phase that transitions from UEFI (BIOS) to Loading the Operating system. So i would, although kinda unwillingly, suggest you to ask the UEFI developers (M$-crapazoids) to add functionality to assist disabled people All other software that interacts with the UEFI, which shim is also, is bound by the rules they set in their specifications regarding SecureBoot...

What? Microsoft isn't the one making UEFI firmware. The UEFI spec doesn't specify that changing Secure Boot settings needs physical access. On top of that the UEFI specification has a whole section about how it's possible for UEFI implementations to do setup configuration over a network.

Even if it did it wouldn't matter as shim is a UEFI application, not part of UEFI. This is much like GRUB or Linux or Windows. shim doesn't have any more power than these OSes or any special treatment. It's not behold to any rules outside its own rules and its own security model that doesn't seem to be really documented anywhere.

In fact the whole purpose of shim is to work around secure boot by implementing its own boot process with its own keys and interface separate from UEFI. If you had an accessible UEFI implementation you would still need accessibility support for all of this, which is what this issue is about.

...

It doesn't look like this discussion is going anywhere productive, so I'm going to bow out. It's getting harder and harder to install an OS on your computer every decade or even just control what your computer does. At this point I'm resigned to just endorsing Windows or macOS. Maybe once ARM machines get a little more powerful Linux will be an option again but as it stands Linux is dead on the desktop for the disabled.

[TriMoon]

After that rant, all i can say or do is showing you the left side to exit :wink: :vulcan_salute:

[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.