[MIR] nullboot

Review for Package: nullboot

[Summary]
nullboot is a boot manager for environments that do not need a boot manager.
Instead of running a boot manager at boot, it directly manages the UEFI boot entries for you.
It produces a Go binary that measures boot binaries and does some sealing,
to allow automatic full disk encryption.
It only operates on trusted data (firmware data and kernels in /usr/lib/linux/efi).

MIR team ACK

This does need a security review, so I'll assign ubuntu-security (package deals with security attestation)

List of specific binary packages to be promoted to main: nullboot_0.3.0-0ubuntu1_amd64

Notes:
Recommended TODOs:
1. It would be nice to have a test plan for end-to-end testing.

- The package should get a team bug subscriber before being promoted

[Duplication]
- There is no other package in main providing the same functionality.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
    - checked with check-mir
    - not listed in seeded-in-ubuntu
    - none of the (potentially auto-generated) dependencies (Depends
      and Recommends) that are present after build are not in main
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
   more tests now.

Problems: None

[Embedded sources and static linking]
OK:
- does not have odd Built-Using entries
- Go Package that follows the Debian Go packaging guidelines
- vendoring is used, but the reasoning is sufficiently explained
- golang: static builds are used, the team confirmed their commitment
   to the additional responsibilities implied by static builds.

Problems: None

[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats
- does not open a port/socket
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)

Problems:
- does deal with security attestation (secure boot, tpm, signatures)

[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite that runs at build time
- test suite fails will fail the build upon error.
- does have a non-trivial test suite that runs as autopkgtest
- no new python2 dependency
- Go package, but using dh-golang

Problems: None

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok (if needed, e.g. non-native)
- Upstream update history is good
- Debian/Ubuntu update history is good
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
   maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- It is not on the lto-disabled list

Problems: None

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as we can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH (usage is OK inside
   tests)
- no use of user nobody
- no use of setuid
- no important open bugs...

The first Lintian warning is due to a bug in dh_strip (bug #1977883).

Hello, this is just a note that the security team is unlikely to review this in time for 22.10. Sorry.

I reviewed nullboot 0.4.0-0ubuntu1 as checked into kinetic. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

nullboot is a specialized lightweight boot manager for environments that don't need one. It works by directly managing the UEFI boot entries. For TPM enabled systems, it also handles the resealing
of the disk encryption key to support boot asset update operations.

- CVE History:
  - No
- Build-Depends?
  - boot and secure boot related libraries
      - canonical/go-efilib
      - canonical/go-tpm2
      - canonical/tcglog-parser
      - snapcore/secboot
  - crypto libraries
      - go.mozilla.org/pkcs7
      - golang.org/x/crypto
- pre/post inst/rm scripts?
  - single postinst script which runs nullbootctl
- init scripts?
  - No
- systemd units?
  - No
- dbus services?
  - No
- setuid binaries?
  - No
- binaries in PATH?
  - /usr/bin/nullbooctl
- sudo fragments?
  - No
- polkit files?
  - No
- udev rules?
  - No
- unit tests / autopkgtests?
  - efibootmgr folder contains an extensive test suite
  - no testsuite for the main application
- cron jobs?
  - No
- Build logs:
  - Warnings:
    - dh_auto_install: warning: LTO opimize is enable in buildflags. But cgo doesn't support it. LTO flags will be stripped in cgo.
    - dh_golang: warning: LTO opimize is enable in buildflags. But cgo doesn't support it. LTO flags will be stripped in cgo.
    - dpkg-gencontrol: warning: package nullboot: substitution variable ${misc:Static-Built-Using} unused, but is defined
    - update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
  - Lintian warnings:
    - W: nullboot: no-manual-page [usr/bin/nullbootctl]
    - W: nullboot source: unknown-field Go-Import-Path
    - W: nullboot: unknown-field Important
    - W: nullboot: unknown-field Protected
- Processes spawned?
  - multiple calls to Go's `exec.Command` in vendored Go libraries. No issues identified.
- Memory management?
  - Written in Go. No issues identified.
- File IO?
  - No issues.
- Logging?
  - No issues.
- Environment variable usage?
  - only in unreachable paths in vendored code. No issues.
- Use of privileged functions?
  - only in unreachable paths in vendored code. No issues.
- Use of cryptography / random number sources etc?
  - Go's crypto library for hashing.
- Use of temp files?
  - Creation of temp files (where applicable) is done inside trusted directories.
- Use of networking?
  - No
- Use of WebKit?
  - No
- Use of PolicyKit?
  - No

- Any significant cppcheck results?
  - No
- Any significant Coverity results?
  - No. Multiple of low impact in vendored code mostly (see attached coverity.txt for a full list)
- Any significant shellcheck results?
  - No
- Any significant bandit results?
  - No
- govulncheck
  - No. 4 vulnerabilities of negligible impact.
- gosec
  - No but
  - several unhandled errors reported such as (see attached gosec.txt for a full list):
    - efibootmgr/bootmgr.go|122 col 2| binary.Write(optionalData, binary.LittleEndian, efi.ConvertUTF8ToUCS2(entry.Options+"\x00"))
    - efibootmgr/reseal.go|183 col 2| binary.Write(h, binary.LittleEndian, uint32(0))

Most of the automated tool...

This is ready to promote, but not showing up as component mismatch right now. Setting "in progress" to reflect that.

You can also prepare an answer to the test plan that you were asked for (in addition to making the change that pull this in).

Ping - This is now in component mismatches

It was considered ready except asking for a few words on a test plan.
So add this and we can promote I guess?

I don't have the means to actually do end-to-end testing *in devel*, for SRUs, the 0.5.0 has this test plan, and I believe CPC folks also test uploads to devel, but I don't know, it's not really a priority since they'll release images using it to the Azure store thingy only if it works.

[Test plan]

* Deploy Azure CVM and TPM FDE
* Upgrade to this new package and reboot
* Boot should be successful
* Double check bios_measurements_log to ensure that the newly update shim was used for boot (https://github.com/canonical/tcglog-parser/tree/master/tcglog-dump can be used to extract checksum of the shim binary used at boot and compared to the one shipped in nullboot)

* CPC - build new image with nullboot preinstalled, and attempt to register and boot such an images as first time.

The end-to-end test plan was a recommendation by the MIR Team. I believe this test plan will be based on FR-5415, which also applies to other bootloaders and Secure Boot.

Julian's test plan sounds good to me +1

Indeed, it was a recommendation only. The framework based on FR-5415 is hosted here publicly: https://code.launchpad.net/~ubuntu-uefi-team/+git/ubuntu-boot-test But it does not currently cover `nullboot`, due to its dependency on Azure CVM. But we have the usual SRU testcase, given by Julian in comment #8.

So I've subscribed ~foundations-bugs to the package, as this is already seeded [1] and seems ready for promotion.

[1] https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?h=noble&id=55bcedf7f75de217cf5693573cd5373c9e9f182b

Thanks for everyone being involved, this is indeed ready for promotion to main.
Thanks for outlining current verification steps until there is automation.

There only is:
 nullboot | 0.5.0-0ubuntu1 | noble/universe | source, amd64, arm64

Pulled in by Ubuntu.Noble supported-cloud seed

Override component to main
nullboot 0.5.0-0ubuntu1 in noble: universe/golang -> main
nullboot 0.5.0-0ubuntu1 in noble amd64: universe/golang/optional/100% -> main
nullboot 0.5.0-0ubuntu1 in noble arm64: universe/golang/optional/100% -> main
Override [y|N]? y
3 publications overridden.