Re: [RFC][PATCH] UEFI Secure Boot support
On 13417 March 1977, Colin Watson wrote:
> The general idea here is to sign a boot loader image (i.e. GRUB) with a
> Debian key: for reasons best known to the UEFI specifiers, this has to
> be a 2048-bit RSA key. The public half of this Debian key would be
> embedded in the shim package, which we would then submit to Microsoft
> for their signature [1]. Upgrading shim would be fairly inconvenient,
> but that doesn't have to be done very often, and this effectively
> arranges to delegate control to a Debian key so that we can change GRUB
> much more easily. shim also implements the "Machine Owner Key" scheme
> so that we can give users a way to add user-controlled signing keys
> without having to figure out how to get at setup mode [2].
So it would be FTPMaster who are responsible for the key, same as the
archive ones.
> Here's a strawman patch to get a discussion started; I've written tests
> for the copier class, but the byhand script is entirely untested.
But modeled after the byhand-di one, so a good start
> The main thing I have not done in this patch is as follows. In Ubuntu,
> we have no manual processing of byhand-style objects; any such object
> has to have entirely automatic processing.
All our regular byhand-style uploads are automated too.
> This means that we have to defend against somebody getting upload
> rights for some relatively inconsequential package and promptly
> uploading a version of it that attaches UEFI malware which we'd then
> merrily sign with our key. To do this, we arrange for any binaryful
> uploads with "raw-uefi" objects attached to hit an UNAPPROVED queue,
> which an ftpmaster then has to accept. I gather Debian doesn't have
> an UNAPPROVED queue as such, but Mark suggested that it could just go
> through NEW.
Either "just" NEW or a combination of NEW and limiting who can upload
that package by our ACLs.
> I am a bit concerned about the idea that any grub2 upload could
> henceforth end up having a multi-day or multi-week turnaround. There
> may not be any real way around this, but any thoughts would be welcome.
If we do it by ACLs, we could have one or three DDs listed with rights
to upload, all the rest either gets rejected or put into NEW. (NEW would
help things like NMUs which otherwise would be forbidden for that
package, which I dont think is the best idea).
We may not yet really support this type of ACL, but the system can sure
be extended to do that. I think it may even work with "those
fingerprints can, all others rejected" already, but that isn't the ideal
way.
It sure also means that, as its fingerprint based, you will have to
- tell us when the grub uploaders change their keys, not only keyring-maint,
- tell us when the maintainers change, ideally signed by an existing
key in that fingerprint list
> Maybe known boot loaders could be whitelisted; but then that means any
> DD could NMU grub2 to get their malware in. On the other hand the
> converse means that now an ftpmaster might have to do at least a cursory
> source review of all grub2 uploads, which might not exactly fill you
> with joy. Comments appreciated.
We can do that. How far we have to understand the code is a different
thing. I wouldn't want to get an expert to fully be able to judge any
change made.
> diff --git a/dak/copy_uefi.py b/dak/copy_uefi.py
Looks like an adjusted copy of copy_installer. I wonder if those two can
be merged. :)
Will see if it works when we get it up and running.
> +++ b/docs/README.stable-point-release
> @@ -60,6 +60,10 @@ if [ "${dioldver}" != "empty" ]; then
> fi
> done
> fi
> +# for each signed UEFI image type:
> +uefitype=grub2
> +uefiver=2.00-21
> +dak copy-uefi -s ${pusuite} -d ${suite} ${uefitype} ${uefiver}
> cd $ftpdir/dists/${suite}
That needs a cleanup part, we don't want to keep the old stuff forever.
> +++ b/scripts/debian/byhand-uefi
[ Wildly cutting parts out ]
> +export SCRIPTVARS=/srv/ftp-master.debian.org/dak/config/debian/vars
> +. $SCRIPTVARS
> +KEYS="$base/scripts/uefikeys"
> +KEY="$KEYS/uefi.key"
> +CERT="$KEYS/uefi.crt"
[...]
> +# This must end with /
> +TARGET="/srv/ftp-master.debian.org/ftp/dists/$SUITE/main/uefi/$TYPE-$ARCH/"
> +mkdir -p "$TARGET"
So you start nicely with using scriptvars and its contents, and then you
overlook the line you got from byhand-di. $ftpdir you want to use here. :)
> +for image in $(find "$TMPDIR" -name \*.efi); do
> + rm -f "$image.signed"
> + sbsign --key "$KEY" --cert "$CERT" "$image"
> +done
That's not in Debian yet. (Or I'm blind)
It should end up in backports at least, thats the usual place DSA
accepts packages outside of stable from.
Alternatively we have to have our own copy, but I don't like this too much.
> diff --git a/tests/fixtures/ftp/dists/testing/main/uefi/grub2-i386/2.00-21/somedir/file b/tests/fixtures/ftp/dists/testing/main/uefi/grub2-i386/2.00-21/somedir/file
Yay, tests.
Do we get this up and ready and usable for jessie?
Note that I wont be able to answer mail the next 3 days, but the next
reply will have a better turnout than 5 months. :)
--
bye, Joerg
It seems to me that the account creation step could be fully automated:
checking the box "approved by DAM" could trigger an insert into the LDAP
database thereby creating the account.
<1375.143.121.153.52.1122977888.squirrel@wm.kinkhorst.nl>
Reply to: