shim-signed trigger should not fail when attempting to re-prompt noninteractively and we've prompted before
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
shim-signed (Ubuntu) |
Fix Released
|
Critical
|
Mathieu Trudel-Lapierre | ||
Trusty |
Fix Released
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned | ||
Yakkety |
Won't Fix
|
Undecided
|
Unassigned | ||
Zesty |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Impact]
Users may require updates to DKMS modules while shim validation is disabled, and expect to do these updates non-interactively, such as via unattended-
[Test Case]
== Interactive ==
(on an EFI system with proper Secure Boot support)
1- Install an old version of a DKMS package (such as bbswitch-dkms or r8168-dkms)
2- Follow the prompts on install to disable shim validation; reboot.
The system should allow you to install the dkms module and prompt you for a password to disable Secure Boot validation in shim. This behavior should remain the same with or without the patch and serves as an extra verification to guard against regressions.
== Uninteractive ==
(on an EFI system with proper Secure Boot support)
1- Install an old version of a DKMS package (such as bbswitch-dkms or r8168-dkms)
2- Follow the prompts on install to disable shim validation; reboot.
3- Run 'sudo apt update'
4- Enable unattended-upgrades (see https:/
4b - If necessary, using PPA packages for testing, allow the PPA source in /etc/apt/
5- Wait/trigger unattended upgrades; observe the behavior:
The user has not installed any new DKMS modules, and we're noninteractive, the trigger should silently pass. Without the patch, this test case should fail (upgrade fails) because update-
== New DKMS package install uninteractively ==
1- Enable unattended upgrades
2- Prepare a new PPA package update that adds a dependency on a -dkms package.
3- Wait/trigger unattended upgrades; observe the behavior.
The user is in effect installing a new DKMS module that was not already present on the system and being upgraded. In this case, the upgrade should fail, because update-
[Regression Potential]
Failure to complete an update in non-interactive (unattended-
[Background information]
The upgrades should run non-interactively without issue whenever possible, but forcefully prompt the user if a new DKMS package is being installed uninteractively:
- If the user installs a new DKMS module, we should not silently proceed. Either the user should be prompted, or if we're noninteractive, the trigger should fail.
- If the user has not installed any new DKMS modules, but we have an interactive frontend, we should prompt.
- If the user has not installed any new DKMS modules, and we're noninteractive, the trigger should silently pass.
---
We currently always fail with an error when update-
It doesn't make sense for a non-interactive package upgrade to fail merely because the user's secureboot setting is ill-advised.
We should ensure that:
- If the user installs a new DKMS module, we should not silently proceed. Either the user should be prompted, or if we're noninteractive, the trigger should fail.
- If the user has not installed any new DKMS modules, but we have an interactive frontend, we should prompt.
- If the user has not installed any new DKMS modules, and we're noninteractive, the trigger should silently pass.
To know whether new DKMS modules have been installed, we should capture the list from /var/lib/dkms and store it under /var/lib/
For upgrade purposes, the shim-signed postinst should detect that we are upgrading from a version of the package that did not yet record the list in /var/lib/
Changed in shim-signed (Ubuntu): | |
assignee: | nobody → Mathieu Trudel-Lapierre (cyphermox) |
importance: | Undecided → Critical |
milestone: | none → ubuntu-17.06 |
status: | New → Triaged |
description: | updated |
description: | updated |
Changed in shim-signed (Ubuntu Xenial): | |
status: | New → Fix Committed |
tags: | added: verification-needed-xenial |
tags: |
added: verification-done-trusty removed: verification-needed-trusty |
Changed in shim-signed (Ubuntu Yakkety): | |
status: | Fix Committed → Won't Fix |
tags: | added: id-594aec8b127c3c2ebe70c166 |
This bug was fixed in the package shim-signed - 1.30
---------------
shim-signed (1.30) artful; urgency=medium
* update- secureboot- policy: track the installed DKMS modules so we can skip secureboot- policy: allow re-enabling shim validation when no DKMS source_ shim-signed. py: add the textual representation of SecureBoot
failing unattended upgrades if they hasn't changed (ie. if no new DKMS
modules have been installed, just honour the user's previous decision to
not disable shim validation). (LP: #1695578)
* update-
packages are installed. (LP: #1673904)
* debian/
and MokSBStateRT EFI variables rather than just adding the files directly;
also, make sure we include the relevant EFI bits from kernel log.
(LP: #1680279)
-- Mathieu Trudel-Lapierre <email address hidden> Fri, 23 Jun 2017 14:37:21 -0400