svn commit: r335402 - head/sbin/veriexecctl

[Simon J. Gerraty]

Conrad Meyer <cem at freebsd.org> wrote:
> First and foremost: nothing is actually signed, anywhere.  The

The signing of manifests is external.  The veriexecctl tool is I assume
a straight copy of what's in NetBSD (I've not looked at it in at least a
decade).

A veriexec loader that leverages signed manifests requires some signing
infra.  That's a big topic all by itself.

As I mentioned in my talk at BSDCan, the signing server we use is open
source and handles pretty much anything OpenSSL can, as well as OpenPGP
(and others).
I also made a point of suggesting that the packages for base system
include signed manifests.

Tweaking the veriexec loader to only process manifests after
verification is not hard - one of the first things I did when pulling
veriexec into Junos almost 15 years ago.

> As a corollary to the above, the name "signature file" is used
> repeatedly in the code, which is misleading.  The file contains hashes
> (digests), not signatures (MACs).  The file itself is unsigned.
> Nothing about this has signatures.

NetBSD refers to the hashes as fingerprints - AFAIK that terminology is
retained.

If the term signature is used to refer to anything other than the signed
manifests that should be fixed.

> There's absolutely no reason to use sha1 or ripemd in new designs.
> These should be removed.

Sorry I disagree - not with ripem (we never supported that or any of the
non-NIST approved hashes), but sha1 is still approved by NIST for
firmware integrity checks - which is what this is, and sha1 is cheaper
than sha256.

As I mentioned in my talk we've included support for sha256 for 10+
years, but do not plan to drop sha1 until NIST deprecate it for that
purpose since boot time is a very sensitive subject for us.

> The patchset is littered with style issues.  One fairly obvious issue
> is mixed indentation styles — some files vary between space and tab
> indentation from line to line.

You can probably blame me for some of that.
I only recently found a style9.el that does a half decent job of
formatting per style(9).

> Please revert this patchset.  It's not ready.
> 
> Some suggestions for a second attempt:
> 
> - Maybe use HMACs instead of raw hashes

Why?

> - Maybe sign the source-of-trust file

We do.  As noted above, we cannot upstream that until FreeBSD has
suitable signing infra.

> - Fix the style issues
> - Fix the compiler warnings at 6