* NOTICE: Backward incompatible Linux-PAM module replacement
@ 2021-03-23 21:38 Joseph Reynolds
0 siblings, 0 replies; only message in thread
From: Joseph Reynolds @ 2021-03-23 21:38 UTC (permalink / raw)
To: openbmc, Andrew Geissler
Please read this if you support firmware downgrade AND if you allow the
BMC admin to dynamically configure the BMC's authentication and password
- Firmware downgrade is firmware update to an older firmware image.
- Dynamically configurable BMC parameters affected include: Redfish
properties AccountLockoutThreshold and AccountLockoutDuration, related
D-Bus properties for RememberOldPasswordTimes, minimum password length,
and includes any on-BMC customization to the /etc/pam.d/ files.
We are seeking approval or strenuous objections to this change.
1. The OpenBMC project is making an incompatible change to its Linux-PAM
2. A new service converts PAM configuration files to adapt to the
changes and preserve existing supported customization.
3. But no backward conversion is planned, so downgrading a BMC across
this incompatible change will cause PAM to fail. And because PAM is
needed for authentication, this will brick the BMC.
Some Linux-PAM modules used by OpenBMC were deprecated and removed from
the underlying Yocto recipes. These modules are no longer supported by
their project, and are no longer available from the Yocto project.
What is OpenBMC doing?
OpenBMC has a temporary patch to use the old unsupported PAM modules to
give time to use the replacement modules. Thanks Andrew! There is a
patch (see below) to use newer PAM modules which provide equivalent BMC
What is the problem?
The patch necessarily changes the PAM configuration files under
/etc/pam.d/. This conflicts with BMC's APIs which allow the BMC admin
to (indirectly) change these same files. If your BMC has any such
changes, they conflict with the changes in this patch! A new conversion
service which runs on the BMC resolves the conflict. See the patch for
details (file libpam_%.bbapend).
This patch provides only a *forward* conversion service, meaning it
converts old config files to new.
Although it would be easy enough to provide a *backward* conversion
service, such a service would have to run on older releases, and we
missed the time window to do that at the project level, and backward
compatibility is not deemed essential for BMCs, and that would add
complexity, so that is a nonstarter.
In summary, you can think of this patch as a downgrade barrier. You can
upgrade without any issues: the conversion service will convert your
BMC's PAM configuration. And you can downgrade without issues if you
don't cross the barrier. Specifically, if you do *not* yet have this
change then you can downgrade to any older version, and if you *do* have
this change then you can downgrade to any older release as far back as
when the change was made, but no further back.
1. Please note the conversion service handles only those items which are
modifiable from supported Redfish and D-Bus APIs. The conversion
service may remove nonstandard on-BMC customized PAM configurations and
reset them to defaults. See the patch for details (file
2. If you have a non-standard PAM configuration built-in to the readonly
/etc/pam.d/ directory AND your BMC does not allow the admin to
dynamically configure these files, then forward conversion should not
need to make any changes, so you have no additional worries.
3. The PAM configuration data is totally independent from the user
account data (/etc/passwd and /etc/shadow). Specifically, the issue
described here does not affect any local user accounts you have
dynamically created on the BMC and does not affect forward or backward
4. The commit message also describes an incompatible operational change:
The pam_tally2 command (invoked from the BMC's command line) is no
longer present. If you used the "pam_tally2 -u USER -r" command to
unlock a user after repeated authentication failures, change to use:
faillock --user USER --reset
The patch is technically two co-requisite patches in different source
repos. These must be applied together, or else you will brick your system:
Can the co-req condition be softened into a pre-req, so one patch could
be applied first, and then the other? This was considered (on the
Discord > OpenBMC > #yocto channel and in earlier gerrit reviews). The
idea is to temporarily have both the old and new PAM modules available
on the BMC, and to enhance phosphor user manager be able to work with
both the old and new PAM configuration files. That approach was rejected
due to complexity.
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2021-03-23 21:38 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-23 21:38 NOTICE: Backward incompatible Linux-PAM module replacement Joseph Reynolds
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).