NOTICE: Backward incompatible Linux-PAM module replacement

NOTICE: Backward incompatible Linux-PAM module replacement

[Joseph Reynolds]

OpenBMC community,

Please read this if you support firmware downgrade AND if you allow the 
BMC admin to dynamically configure the BMC's authentication and password 
related parameters.
- 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.

Thanks,
Joseph


Summary:

1. The OpenBMC project is making an incompatible change to its Linux-PAM 
configuration.
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.


What happened?

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 
security function.


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.


Notes:

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 
convert-pam-configs.sh).

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 
migration.

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:
1) https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/41357
2) 
https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-user-manager/+/39853

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.