[PATCH 2/2] Add encrypted file support

Timothy Pearson tpearson at raptorengineering.com
Wed Aug 3 13:07:08 AEST 2016


On 08/01/2016 11:16 PM, Samuel Mendoza-Jonas wrote:
> On Mon, 2016-08-01 at 12:10 -0500, Timothy Pearson wrote:
> 
> What is the origin of the pb-lockdown file? Is it possible to verify
> that it hasn't been tampered with (ie. if a user has managed to drop to
> the shell)? Presumably this assumes the initrd from the PNOR can be
> trusted.

It is generated when the initrd is created, along with preloading the
root GPG keyring with the machine owner's keys.  Our risk model assumes
that the initrd, kernel, and root userspace are not compromised, as a
compromise in any one of those three would allow unauthorised access by
definition.

This is only one link in the security chain -- our next steps will be to
sign the petitboot kernel and initrd in PNOR and verify those signatures
from the firmware itself.  These patches at least allow a
write-protected firmware image to boot a secure operating system if the
machine is also located in a physically secure environment.

> Same comment about the error codes - if they're not being read it's fine
> to just return -1.

Fixed.

> This looks the same as the init in verify_file_signature() - would it
> make sense to have this in it's own function that gets called once
> before verify_file_signature() and decrypt_file()?

I'm somewhat hesitant to split up the verification code; while it may be
somewhat redundant it can be useful for auditing to see the entire GPG
setup through verification / decryption in one linear chunk of code.

> Ah so this is probably why the source files get copied to /tmp/ in
> patch 1.

Not exactly (see previous message), but it's a nice side effect. :-)

> If the verify_file_signature(..initrd..) fails but
> verify_file_signature(..dtb..) passes, will this mistakenly set result
> again and think both have passed?

No.  The result variable is effectively "trip once"; no code resets it
to zero (pass) so once set to a non-zero value it will always fail.

-- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com


More information about the Petitboot mailing list