ipmi password storage

[Joseph Reynolds]

On 4/14/20 2:14 PM, Vernon Mauery wrote:
> On 14-Apr-2020 06:04 PM, Milton Miller II wrote:
>> On Apr 13, 2020 around 6:01PM in some time zone, Vernon Mauery wrote:
>>>
>>> Internally, an issue was raised that basically says that the
>>> mechanism
>>> by which we are storing the IPMI passwords on the BMC is
>>> insufficiently
>>> obfuscated. I have come up with a patch set that resolves this at the
>>>
>>> expense of no downgrading the BMC without the side-effect of losing
>>> all
>>> IPMI passwords. I would like to know what the community thinks about
>>> usability vs. security in this scenario.
>>
>> ...
>>
>>> The migration from the old mechanism to the new could be done simply>by
>>> using the new key on the next write to the /etc/ipmi_pass file. After
>>> a
>>> firmware update to this new code, a password change would trigger a
>>> decrypt of the /etc/ipmi_pass file, a modification of the plain text,
>>>
>>> and a re-encryption of the data. If it reads the 'legacy' key in and
>>> writes out the data using the new key mechanism and deletes the
>>> legacy
>>> key, it would use the new key mechanism from that point onward.
>>> However,
>>> this would cause any downgrades to prior versions to fail to decrypt
>>> the
>>> /etc/ipmi_pass file, thereby losing all the ipmi passwords. This is
>>> not
>>> ideal, but could possibly be mitigating by truncating the new
>>> machine-id
>>> derivative password to 8 bytes and storing it in the /etc/key_file
>>> instead of just deleting it. This might improve security only
>>> slightly
>>> at for the price of a better user experience.
>>>
>>
>> I'll point out the code to handle the new password could be added
>> before the cdoe to use the new method, allowing test and revert
>> until the users are upgraded to the new method.  It does require
>> both methods to be supported.
>
> Yes, it looks like any sort of change here would need to be a staged 
> change to reduce the disruption.

Thanks for handling this issue -- I appreciate it.  Don't take this the 
wrong way, but...
If this change provides little value and causes upgrade issues, would it 
be better to avoid having an upgrade path?
Instead, use this new approach for new major release that requires a 
fresh install and upgrading is not an option.

>
>> I didn't follow why currently all openbmc systems end up with
>> the same encryption^Wobsfucation for what that is worth.
>
> Unless the build has a bbappend that changes the contents of the 
> key_file that is a part of the pam-ipmi package, all of the builds 
> will contain that same key_file. I can't say for sure how many builds 
> have this already, but I did not see much documentation around that 
> fact that would have spurred people to take action, so it is my 
> assumption that most builds would use the default.

 From previous emails in this thread, it doesn't seem like having each 
BMC having an unique key_file would help much.  Nevertheless, I've added 
this to my notes for BMC build considerations: 
https://github.com/ibm-openbmc/dev/issues/1531#issuecomment-613676676

- Joseph

>
> --Vernon