Trust system write-up

[Eric McCorkle]

On 10/23/2017 12:44, Simon J. Gerraty wrote:
> Eric McCorkle <eric at metricspace.net> wrote:
>> That is also an option; however, I prefer the configuration where only
>> the local system key is a root and everything else is an intermediate,
>> as each root key represents a source of trust that is hard to revoke
>> (you have to power-cycle).  It's almost always better to have a single
>> root, and make everything else an intermediate, though I'm not sure
>> enough of that to bake it into the specification.
> 
> While we as an embedded vendor might not necessarily want to support any
> local signing ability - or to be able to limit the scope of any such
> ability, there should be no reason you cannot allow a FreeBSD.org root
> cert to be honored in parallel with local root.  This should allow
> updating system with both locally build s/w and pre-built packages from
> FreeBSD.

You could do that.  You can have as many root certs as you'd like.  The
rationale behind the "preferred" configuration is that it's simpler
(fewer attack vectors) and it takes a stance that users should have
exclusive control over their own machine.  But nothing stops you from
installing any number of vendor certs as roots.

> 
> FWIW when designing the trust model for Junos, preventing any local 
> control of trust store was an explicit goal.
> With the advent of secure boot and TPM's, there is potentially scope to
> allow for mixed control.

That sounds similar to the high-security setup I described.

> Please have a look at stevek's mac_veriexec patches in phabricator.
> The verified exec model easily allows for "signing" any sort of file,
> not just ELF binaries or needing to use special "attached" signature
> formats.  Thus it allows adding "signing" with minimal impact to most of
> the system.   This could probably work well in conjunction with your
> trust database.
> 
> And of course my loader mods follow the same model, so signing
> loader.conf, modules etc is all simple with minimal impact to loader
> itself.

I've seen that work.  The NetBSD veriexec stuff is of interest.  I don't
really see it as a "competing" approach, more of a closely-related
security mechanism.  I don't see any reason why both mechanisms couldn't
coexist, and there's probably some sort of beneficial interaction
between the two.  I could see, for example, veriexec being used to
protect specific files from tampering, with the MACs themselves being
provided by a signed file.

I'm a bit less enthusiastic about veriexec in the loader.  The problem
there is it requires an update to the loader every single time you build
a new kernel, whereas the public key approach only needs updating if you
change root keys.  (That's really the key difference: veriexec is an
anti-tampering mechanism, where the trust system I've described is a
trust-delegation mechanism).