Supporting insecure protocols in RMCP+

Brad Bishop bradleyb at fuzziesquirrel.com
Wed Apr 25 03:52:53 AEST 2018


> On Apr 24, 2018, at 11:34 AM, Vernon Mauery <vernon.mauery at linux.intel.com> wrote:
> 
> On 24-Apr-2018 09:17 AM, Brad Bishop wrote:
>> 
>>> On Apr 23, 2018, at 3:30 PM, Vernon Mauery <vernon.mauery at linux.intel.com> wrote:
>>> 
>>> On 23-Apr-2018 11:47 AM, Vernon Mauery wrote:
>>>>> Patch Set 4:
>>>>> 
>>>>>> Given that RMCP+ is already insecure, unless it is a requirement to support 1, 2, 15, and 16, you may just want to support 3 and 17.
>>>>> 
>>>>> 1,2,3 are marked as mandatory in the specification. It should be a community decision to revoke support for 1,2. If the community is ok, it will need additional code changes.
>>>> 
>>>> tl;dr IPMI is old; let's drop the most insecure parts
>>> 
>>> While I am at it, can we agree
>> 
>> I agree with all your points.  But why is consensus necessary?
> 
> Consensus is best when we are intentionally going against the IPMI standard.

This was a trick question.  I don’t think we should be limiting behaviors
in OpenBMC.  As in, if someone wants to comply to this part of the spec,
they should be able to do that.  If someone wants to skip this part of the
spec, they should also be able to do that.

If you accept that world-view, there isn’t anything left to find consensus
on other than which behavior is the default.

> With IPMI, there may be several of these things where we might want to break the standard in order to provide better security. But I don't think we can do that unilaterally.
> 
> --Vernon
> 
>>> that anonymous and nameless accounts are dangerous. I know that the IPMI spec says that having an account with no name is mandatory, I think this is another case of security trumps the standard.
>>> 
>>> I would at least like a way to disable this at build time so we CANNOT have this exploited.
>> 
>> That sounds like a reasonable way to make the code do what you need.
>> 
>>> 
>>> --Vernon


More information about the openbmc mailing list