[PATCH 2/2] Add encrypted file support

[Samuel Mendoza-Jonas]

On Tue, 2016-08-02 at 22:07 -0500, Timothy Pearson wrote:
> 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.

Right

> 
> 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.

In that case you should definitely have a look at what some IBM people
are doing in that area to bring trusted boot to op-build.
Stewart - are there some posted/merged patches to that effect that
illustrate what IBM has done so far?

> 
> > 
> > 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.

Ah right you are, I misread it - I see you only ever set it to fail.

>