veriexec: add strict mode

[sebastien.bini_stormshield.eu]

Summary

When sending verified files to /dev/veriexec, veriexec returns
successfully as long as it verified the manifest, even if not any
file of the manifest exists on the filesystem.

This leaves an open door for potential attacks. This PR adds a new
option to veriexec so that it returns an error code if some files are
missing. Hence we can easily detect that something is wrong.

[sjg]

What is the attack ? If veriexec is enforced, trying to load a bogus manifest does not achieve anything.
Why not just call the variable ioctl_errors ? An ioctl failure need not be due to an injection attack.

[sjg]

In D36678#833236, @sjg wrote:

What is the attack ? If veriexec is enforced, trying to load a bogus manifest does not achieve anything.
Why not just call the variable ioctl_errors ? An ioctl failure need not be due to an injection attack.

I should probably elaborate: if the manifest verifies ok - the manifest is legitimate.
We deliver our s/w in immutable iso images - which mitigates a lot of problems, but in general; upgrading a box after 10 years, provides lots of scope for innocent failure modes.
Being unnecessarily strict can do be counter productive.

[sebastien.bini_stormshield.eu]

In D36678#833237, @sjg wrote:

I should probably elaborate: if the manifest verifies ok - the manifest is legitimate.
We deliver our s/w in immutable iso images - which mitigates a lot of problems, but in general; upgrading a box after 10 years, provides lots of scope for innocent failure modes.
Being unnecessarily strict can do be counter productive.

This is related to our upgrade process. The upgrade tarball is verified (not by veriexec) and is then extracted ; this is done in an uncontrolled environment (users can still be connected in ssh for instance). At some point the product switches to a controlled environment (init is the only running process) and the upgrade begins its installation. We want to make sure we are indeed installing an upgrade file, as because when an upgrade is detected, some security fences are lowered (and can be permanently lowered if the upgrade is not legitimate).

The upgrade also comes with a veriexec manifest. We thought of verifying and sending the manifest, while in the controlled environment, to make sure that the upgrade files are what they claim to be. However this approach is still vulnerable. We realized that someone could "forge" upgrade files by making several hard links to true (true being verified by mac_veriexec, those files will be as well). In addition they could copy an existing manifest and name it as the one that should come with the upgrade. As such, when we perform our verification in the controlled environment, the upgrade files are detected, the "upgrade" manifest is successfully verified (but does not list upgrade files, and this is silenced by veriexec). Then we see that the upgrade files are verified, and as such we lower the security fences. Those fences are supposed to be put back by the upgrade files, but since they are just hard links to true, they are permanently removed.

Now that I explain it, I can think of other attack scenarios. This is not bullet-proof :/ I am going to drop this.

[sjg]

I find phab a tough medium for discussion, feel free to send me email.