Staging plans to remove network IPMI support?

[Joseph Reynolds]

On 9/20/19 10:48 AM, Vernon Mauery wrote:
> On 18-Sep-2019 04:34 PM, Joseph Reynolds wrote:
>> Re-sending to fix up formatting error:
>>
>> The OpenBMC security working group discussed a desire to remove out-of-band
>> network IPMI support from the OpenBMC firmware stack, here:
>> https://lists.ozlabs.org/pipermail/openbmc/2019-September/018319.html
>>
>> This would affect out-of-band (network IPMI) only, in repository
>> https://github.com/openbmc/phosphor-net-ipmid. The host IPMI support is
>> a separate topic.
>>
>> The *main idea* is a staging plan to remove network IPMI support over a
>> period of years, like in this progression:
> This may be a year 3030 topic; I would not worry too much about it for
> now. By the time RMCP+ is gone, BMCs may not even be a thing anymore :)
>
> But in all seriousness, telnet and rlogin stayed on for YEARS beyond
> their welcome. It will be a difficult task to wean users off RMCP+. It
> is so easy to use and we are all used to it. Redfish is so complicated
> and we don't have the tooling to make it work as smoothly as RMCP+.
>
> Basically what I am saying is that we need buy-in from the end users. So
> far, for all its wonder and glory, Redfish really has been a hard sell.
> For all the warts and flaws of RMCP+ over IPMI, people *need* it. People
> are not rational and do not make security decisions based on logic.

Agreed :)

Do you think it would be helpful to add the staging plan discussed here 
to the "Provide alternatives to network IPMI" wish list item? See 
https://github.com/openbmc/openbmc/wiki/Security-working-group#security-feature-wish-list

>
>> 1. Tell everyone the plans at each stage below. For example: emails to the
>> group, mention in the release notes, update
>> https://github.com/openbmc/phosphor-net-ipmid/blob/master/README.md and the
>> ipmitool repo.
> We can certainly add something to the README, but we do need to set some
> expectations on how much people actually read documentation. Adding
> something there will not have nearly as much effect as putting a big red
> banner on the bmcweb console that says "IPMI over RMCP+ is enabled and
> is insecure. You might consider disabling it and using the Redfish
> protocol instead"

Good idea.  Like a security health check for the BMC's interfaces. I'm 
tracking an issue (work item) to disable IPMI via Redfish (here 
https://github.com/ibm-openbmc/dev/issues/612), and I've added this as a 
suggestion.

>
> OpenBMC does not own the ipmitool project (or any of the other
> opensource utilities that speak RMCP+), so we will need to reach out. It
> turns out that the ipmitool maintainer is a member of the OpenBMC
> community, so we can hopefully leverage that relationship.
>
>> 2. Implement the Redfish ManagerNetworkProtocol - defined in the DMTF
>> Redfish Resource and Schema Guide DSP2046 https://www.dmtf.org/dsp/DSP2046.
>> This gives the BMC admin an interface to disable out-of-band network
>> IPMI.That means stopping the IPMI network service and closing its port.
> I keep hearing stories about redfish not being united and common enough
> to be useful. Does the spec need to grow or do we just need to make sure
> that it is always implemented according to the spec?

My reading is that OpenBMC is committed to Redfish and member of the 
OpenBMC community are actively working to enhance Redfish to do what we 
need.

- Joseph
>
>> 3. Change the IPMI ManagerNetworkProtocol setting to be disabled by
>> default.  After this, BMC admins have to take an explicit action to enable
>> IPMI access.
> I would hope that long before we disable netipmid by default, Redfish
> would be the main mechanism for accessing the BMC.
>
>> By this point it should be possible to learn how to migrate from
>> IPMI to Redfish APIs.
> No, people should be learning how to migrate from IPMI to Redfish right
> now, long before we attempt to disable RMCP+/IPMI by default.
>
>> 4. Remove IPMI from the default OpenBMC configuration. This means network
>> IPMI is not built into the BMC firmware image. After this, project who want
>> to use network IPMI will have to explicitly add it to their image. This will
>> hopefully be a wake-up call to anyone who is still using network IPMI.
> I think this step could be moved up. Not every OEM user of OpenBMC wants
> to include netipmid in their builds today. Adding a package to an image
> is just as easy as removing it. We could make it NOT part of the image
> by default and require all OEMs that want it to add it to their image.
>
>> 5. Remove all references to network IPMI from OpenBMC.
> I am not sure this is ever necessary. This is not a nanny state. If
> someone wants openBMC to have insecure packages on their builds, that is
> up to them. We can disable the package by default, but I think that is
> as far as we need to go.
>
> --Vernon