Allow for password less connectivity using the native linux OpenIPMI kernel driver interface.

[ArKam]

Linux allow direct RO access to the HW BMC without needing to authenticate (ipmitool use that interface by default) on compatible hardware such as any HPE/DELL or Supermicro server.

Could the exporter try to use this interface when run without the --secrets.static option? That would allow us to use the bmc_exporter as a deamonset on our nodes without having to open the IPMI Over Lan feature.

Let me know if you need further informations.

[gebn]

I'm not against this, and would be happy to review a PR!

[mahendrapaipuri]

@gebn Does the bmc package support executing IPMI commands without a session context? For instance is it possible to do something equivalent of ipmitool dcmi power reading with bmc package?

[gebn]

The bmc package implements IPMI over a network interface. There are commands that may be sent outside a session (i.e. unauthenticated), however these are still UDP packets. I'm not sure how much difference there is in the local vs. remote protocol.

[mahendrapaipuri]

@gebn Cheers!! Yes, that is what I understood from bmc package code. Do you have any plans on supporting local protocol for bmc package?

We have a pretty similar use case as @ArKam that we would like to deploy the exporter as daemon on compute nodes and we prefer to avoid LAN comms with IPMI.

[gebn]

No plans I'm afraid, but happy to help integrate a PR. In theory it should be sending the same bytes over a different kind of socket.

[ArKam]

I’ll have a look at the bmc library, but the whole OpenIPMI interface model is network interface/session free as it directly leverage the kernel modules/interface.

I don’t know if we can do something to tell bmc to use a specific interface implementation.

To be noticed:

On our own opinion, the fact that the OpenIPMI allow for unauthenticated/unsegregated direct high level access to the BMC is a security flaw if not a security issue as it basically provide anyone on your linux system having enough privileges the ability to hot reconfigure its own bmc at will.

We especially noticed that on DELL/HPE latest and brightest hardware iLO/iDRAC this can’t even be blocked at the BMC level as explicitely requiring auth from host is simply just plain ignored by the kernel module that leverage DMA to access the bmc and operate changes.

[mahendrapaipuri]

I’ll have a look at the bmc library, but the whole OpenIPMI interface model is network interface/session free as it directly leverage the kernel modules/interface.

Not just OpenIPMI, most of common IPMI implementations support this.

On our own opinion, the fact that the OpenIPMI allow for unauthenticated/unsegregated direct high level access to the BMC is a security flaw if not a security issue as it basically provide anyone on your linux system having enough privileges the ability to hot reconfigure its own bmc at will.

I would not say so. When IPMI driver on kernel is loaded, it exposes a device file at /dev/impi0 which is only accessible for root. As @gebn said, we send the same bytes as we do for LAN connection to BMC via this device and read back response. So, only root or any process with cap CAP_DAC_OVERRIDE can read/write to this device. The auth is imposed in this so-called in-band IPMI access based on POSIX permissions.

[ArKam]

Not just OpenIPMI, most of common IPMI implementations support this.

I was more specifically refering to the open interface, not really implementation of the specification, if you look at the supported interfaces usually you'll find:

• open
• imb
• lan
• lanplus
• serial-terminal
• serial-basic
• usb

I would not say so. When IPMI driver on kernel is loaded, it exposes a device file at /dev/impi0 which is only accessible for root. As @gebn said, we send the same bytes as we do for LAN connection to BMC via this device and read back response. So, only root or any process with cap CAP_DAC_OVERRIDE can read/write to this device. The auth is imposed in this so-called in-band IPMI access based on POSIX permissions.

Although I agree that a simple user can't access to the device or would require a privilege escalation, as a root user you still can change your BMC access rights and settings without any authentication, which is where the security issue live for us as root operators of the nodes may be of different profiles than the operators of the platform (IaaS with BareMetal As A Service).

I'm pretty sure that I can found a lot of accessible servers (public/private) that have improper sudo configuration for convenience, privilegied containers or even hypervisor that expose the ipmi device to the guest VMs, that would let all those workload to easily kick you (operator/maintainer of the node) out of it.

I agree that it's a reasonable risk with a rather low blast radius, but still not having proper authentication on the device (even if it's directly attached to the host) seems very odd as of 2024.

But all in all that up for another topic and pretty much unrelated to this specific use case/issue request that we would like to leverage too anyways ^^.