ipmi password storage

Vernon Mauery vernon.mauery at linux.intel.com
Wed Apr 15 08:47:46 AEST 2020


On 14-Apr-2020 05:30 PM, Joseph Reynolds wrote:
>>>>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.
>

It doesn't cause upgrade issues, it would cause downgrade issues. While 
I am not personally opposed to not downgrading (always move forward), 
not all IT shops have the same opinion. I thought it might be nice to 
offer an opportunity to support downgrades.

--Vernon

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


More information about the openbmc mailing list