Verified execution (veriexec) device interface to MAC/veriexec

[stevek]

Summary

Device for user space to interface with MAC/veriexec.

The veriexec device features the following ioctl commands:

• VERIEXEC_ACTIVE
  • Activate veriexec functionality
• VERIEXEC_DEBUG_ON
  • Enable debugging mode and increment or set the debug level
• VERIEXEC_DEBUG_OFF
  • Disable debugging mode
• VERIEXEC_ENFORCE
  • Enforce veriexec fingerprinting (and acitvate if not already)
• VERIEXEC_GETSTATE
  • Get current veriexec state
• VERIEXEC_LOCK
  • Lock changes to veriexec meta-data store
• VERIEXEC_LOAD
  • Load veriexec fingerprint if secure level is not raised (and passes the checks for VERIEXEC_SIGNED_LOAD)
• VERIEXEC_SIGNED_LOAD
  • Load veriexec fingerprints from loader that supports signed manifest (and thus we can be more lenient about secure level being raised. Fingerprints can be loaded if the meta-data store is not locked. Also securelevel must not have been raised or some fingerprints must have already been loaded, otherwise it would be dangerous to allow loading. (Note: this assumes that the fingerprints in the meta-data store at least cover the fingerprint loader.)

Depends on D8554

Test Plan

Various versions of this code (with some differences) has been in use for a few
years and has gone through in-house testing.

[jtl]

sys/dev/veriexec/verified_exec.c

124 ↗

(On Diff #22310)

Can you explain why we need both VERIEXEC_LOAD and VERIEXEC_SIGNED_LOAD?

You are trusting the userspace program to correctly self-identify whether it is loading a signed manifest. Why not also trust it to check the secure level prior to loading an unsigned manifest?

178 ↗

(On Diff #22310)

Right. This is important because the system doesn't verify hashes if the file is on MNT_VERIFIED (since the file system's underlying storage was already verified in bulk). That is another subtlety that should go in a man page...

[jtl]

I think this should be committed basically "as is", unless someone raises serious objections in the next week or so.

This has years of "soak time". I've also personally stared at this code for many hours over many years.

As I said in one or more of the other reviews, this needs additional documentation. And, it may need some additional infrastructure to make it more easy to use in the generic FreeBSD use case. But, I don't think it is worth holding this up for a missing man page, and we can add some of the additional non-Juniper infrastructure once Juniper's contribution is committed.