To restrict IPMI commands

[P. K. Lee (李柏寬)]

> On Apr 2, 2019, at 03:39, Vernon Mauery <vernon.mauery at linux.intel.com> wrote:
> 
> On 28-Mar-2019 02:33 PM, P. K. Lee (李柏寬) wrote:
>> 
>> 
>>> On Mar 27, 2019, at 22:39, Brad Bishop <bradleyb at fuzziesquirrel.com> wrote:
>>> 
>>> On Sat, Mar 16, 2019 at 01:04:53PM +0000, P. K. Lee (李柏寬) wrote:
>>>> Hi Vernon,
>>>> 
>>>> Thank you for providing a new filtering mechanism that looks very
>>>> flexible, but I have a question.  I have tried the filter that allows
>>>> filtering of commands by whitelistFilter, but the channel of request
>>>> must be channelSystemIfac to check the contents of the whitelist.  What
>>>> puzzles me is why channelSystemIfac is in the constraint? This
>>>> constraint will cause the whitelist to fail when the user calls the
>>>> IPMI command via the LAN.  If the user wants to use the whitelist vis
>>>> the LAN,
>>> 
>>> Hi P.K.
>>> 
>>> If I understand correctly, you want to have a system that operates in
>>> one of two modes - restricted or un-restricted.  When the system is in
>>> restricted mode, only whitelisted commands will be processed from _any_
>>> channel.  Do I understand correctly?
>> 
>> Yes, we need to use the whitelist mechanism to restrict IPMI commands
>> from any channel.
>> 
>>> How do you restore the system to unrestricted mode?  Some side-band (non
>>> IPMI) mechanism?
>> 
>> For us, it can use the REST to change the restriction mode as well.
>> 
>>> If you are able to share, I'm curious to know more about the usage
>>> pattern driving the need for this.
>> 
>> I thought that the configuration can be modified the format of
>> <NetFn>:<Command>:<Channel> to apply the whitelist with multiple channels,
>> where <Channel> uses 2 bytes to map the channel using a bit array.
>> 
>> For example:
>> 0x06:0x01:0xFFFE  // The 0xFFFE is used 2 bytes to represent the channel 1~15
>> 
>> However, in order to be compatible with the current design, the <NetFn>:<Command> still only uses the system interface.
> 
> This is a reasonable mechanism to extend the whitelist to multiple interfaces for a fixed setup. Is there a need to make the filtering more flexible, like runtime changing which commands are available? If so, does the layout of the IPMI2.0 firmware firewall work?
> 
> —Vernon

I thought that the whitelist is provided by the vender, and the firmware firewall is the part that the customer can customize. In a security-based restriction, the customer cannot execute commands that are not in the whitelist.
Of course the customer can't discover the command that is not in the whitelist, just as the command does not exist. In order to distinguish the difference from the firmware firewall in the completion code, the completion code of the command that is not in whitelist can be changed to C1h.

Best,
PK