search

ibm-openbmc / dev

Product Development Project Mgmt and Tracking
16 stars 2 forks source link

Allow admin to disable BMC SSH, IPMI, and HTTP access #612

Closed joseph-reynolds closed 2 years ago

joseph-reynolds commented 5 years ago

Expected Delivery Dates

Stakeholders

SME: Joseph Reynolds Design Researcher: @ParishrutB @priyanka-pillai97 UX Designer: @ParishrutB @priyanka-pillai97 FED: @dixsie

Use Case

The BMC admin should have an option to disable BMC shell access as a way to ensure the system is managed only by its intended interfaces (like Redfish REST APIs). Security conscious users will want to disable shell access when build the OpenBMC image or when provision their BMC. They require that, for example, to better control and log use of the BMC's management functions, and to pass audits. Use cases are (1) large-scale data centers where uniform access is desired, and (2) systems with sensitive (personal, financial, etc.) data where shell access constitutes a back door into the system.

Specifically, when disabled, secure shell (ssh) access to the BMC (ssh -p 22) will fail. Note that ssh access to the host console (via ssh -p 2200) is not affected by this design.

The admin will be able to re-enable access, allow the BMC shell to be used for some function, debugging, or whatever, and then disable access again. Presumably use of the shell will be a rare event and closely watched to ensure no back doors into the BMC are created.

The BMC admin should be able to log the fact that BMC shell access was disabled or re-enabled. For example, if the design implements the Redfish ManagerNetworkProtocol SSH property (reference below), then Redfish REST API logging would suffice. The BMC admin should also be able to log ssh connection attempts, for example, log files written by the ssh server, PAM, etc.

Requirements

Design

We don't want the GUI to turn this function on or off by accident. My crude GUI design sketch: I envision a new status field on the admin page that shows if "BMC shell access is enabled" (and clearly indicate this feature is separate from the "host console ssh" feature). Maybe have a way to change its state, indicating one of:

Development

Shell access will remain enabled by default in the current OpenBMC releases.

InVision Prototype

Design Issue (phosphor-webui)

Development Issue

References/Resources

rfrandse commented 4 years ago

refresh

joseph-reynolds commented 4 years ago

We should show how network users ingress into the BMC so BMC admins understand how to disable access.

The following diagram is a simplified view of how a network agent accesses a BMC interface, authenticates, and accesses a function.

Network agent
   |
+--|-----------------------------
|  |                        BMC
|  V        
| Network interface:
|     one of
|      - HTTPS
|      - SSH
|      - IPMI
|      - etc.
|   |
|   V
| Authentication of user: local accounts and optionally LDAP
|     root, adminuser, joeuser, etc.
|   |
|   V
| Function:
|  - Redfish REST APIs
|  - Secure Shell
|  - IPMI server
|  - etc.
+--------------------------------

The BMC admin can control access in these ways:

rfrandse commented 4 years ago

refresh

rfrandse commented 4 years ago

refresh

rfrandse commented 4 years ago

refresh

rfrandse commented 4 years ago

refresh

rfrandse commented 4 years ago

refresh

rfrandse commented 4 years ago

refresh

joseph-reynolds commented 4 years ago

I came up with a draft version of the wording to help users understand what “enabled and disabled” mean for each item. My best guesses are in the bullets below, but we will probably have to tweak the wording (because I am not an expert in each of those areas):

rfrandse commented 4 years ago

refresh

joseph-reynolds commented 4 years ago

Should we add SoL to the list? It is a similar access as KVMIP which is on the list. See https://lists.ozlabs.org/pipermail/openbmc/2020-April/021148.html

joseph-reynolds commented 4 years ago

I've proposed adding ManagerNetworkProtocol.Oem.OpenBMC.mDNS as the mechanism for the BMC admin to enable and disable the BMC's Avahi mDNS service.

rfrandse commented 4 years ago

refresh

rfrandse commented 4 years ago

refresh

rfrandse commented 4 years ago

refresh

rfrandse commented 4 years ago

refresh

rfrandse commented 4 years ago

refresh

rfrandse commented 4 years ago

refresh

joseph-reynolds commented 4 years ago

Progress on REST APIs to disable out of band IPMI (aka network IPMI) ~ https://lists.ozlabs.org/pipermail/openbmc/2020-May/021686.html

rfrandse commented 4 years ago

refresh

rfrandse commented 4 years ago

refresh

rfrandse commented 4 years ago

refresh

rfrandse commented 4 years ago

refresh

rfrandse commented 4 years ago

refresh

rfrandse commented 4 years ago

refresh

rfrandse commented 4 years ago

refresh

rfrandse commented 4 years ago

refresh

rfrandse commented 4 years ago

refresh

rfrandse commented 4 years ago

refresh

rfrandse commented 4 years ago

refresh

rfrandse commented 4 years ago

refresh

rfrandse commented 4 years ago

refresh

rfrandse commented 4 years ago

refresh

rfrandse commented 4 years ago

refresh

rfrandse commented 4 years ago

refresh

joseph-reynolds commented 4 years ago

Desire to disable the Redfish protocol stated here: https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/35457/8//COMMIT_MSG#51

rfrandse commented 4 years ago

refresh

joseph-reynolds commented 4 years ago

This table summarizes the work needed to disable interfaces through the BMC's architectural layers. The interfaces are listed across the top. The layers are listed down the left side. Each cell details the solution or work needed.

WORK IN PROGRESS -- please edit for correctness

Work items Network IPMI SSH HTTPS phys USB RTAD (host)
WebUI #1273 #1273 #1273 #1273 #1273
Redfish API #513 #1763 #1763 #1781 BIOS settings (Ratan)
D-Bus done? (need refefence) same same #1793
lower-level n/a n/a n/a #1793

No support is planned to disable:

See also:

rfrandse commented 4 years ago

refresh

rfrandse commented 3 years ago

refresh

rfrandse commented 3 years ago

refresh

rfrandse commented 3 years ago

refresh

rfrandse commented 3 years ago

refresh

mzipse commented 3 years ago

refresh

rfrandse commented 3 years ago

refresh

rfrandse commented 3 years ago

refresh

rfrandse commented 3 years ago

refresh

rfrandse commented 3 years ago

refresh

derick-montague commented 3 years ago

@joseph-reynolds is looking into how the current design being proposed will impact a system if there were to be quick enable and disable of settings. This is based partially on this comment:

Having the ability to disable shell access in regular scenarios would be good, as long as we can re-enable without too much disruption to the state of the BMC. https://github.com/ibm-openbmc/dev/issues/612#issuecomment-492121453

The current design would allow the user to enable and disable without any confirmation, so the changes to the same setting could be made rapidly. We want to assure, given the comment about potential disruption to system state, the proposed interface without any confirmation to the user to make the change is acceptable.

image

joseph-reynolds commented 3 years ago

On the question of: What is the effect of disabling an interface, or enabling that interface, and should a GUI interface tell an admin what the effects are (like with help text) or require confirmation (like with a modal dialog box to confirm)?

These are currently DRAFT text, are not recommendations for help text (these may be too obvious to explain), and have NOT been reviewed by either technical development (for accuracy) or information development (technical writers, for clarity).

In general, for all interfaces: Having an interface enabled exposes you to newly discovered security vulnerabilities in that interface. However, the decision to disable an interface must be balance with requirements to operate and service the system. For example, you could disable the BMC's "SSH port 22" and re-enable it only as needed for service.