Initial expired passwords - low level designs

[Ratan Gupta]

Hi Joseph,

On 19/08/19 10:32 PM, Joseph Reynolds wrote:
> This is an attempt to over-communicate progress on the [Initial 
> expired passwords design][], currently in review.  This email has the 
> significant and tricky work items needed to implement the design. 
> Emails about the BMCWeb pieces that need to be changed are [here][]; 
> in contrast, this email attempts to decompose the overall design.
>
> [Initial expired passwords design]: 
> https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/23849
> [here][]: 
> https://lists.ozlabs.org/pipermail/openbmc/2019-August/017625.html
>
> The "initial expired passwords design" includes the following work. An 
> understanding of that design is a pre-requisite to understand the 
> items here.
>
> 1. Implement the new EXPIRED_PASSWORD image feature (initially off).  
> This ensures the password is expired for all local users. The right 
> place to do this piece is in Yocto/OpenEmbedded; see 
> https://lists.yoctoproject.org/pipermail/yocto-security/2019-July/000114.html
>
> 2. Enhance BMCWeb to handle Redfish PasswordChangeRequired (reference: 
> https://www.dmtf.org/sites/default/files/standards/documents/DSP0266_1.7.0.pdf 
> ("Redfish Specification" version 1.7.0 or later) section 13.2.6.1).
> This further breaks down into:
>
> 2a. Add the PasswordChangeRequired field to 
> /redfish/v1/SessionManager/Sessions/<session>.  This new field comes 
> from PAM_NEW_AUTHTOK_REQD.
   Are you mentioning the OEM filed in the session schema ? I think that 
we should define a new error message that will tell that password change 
required during creation of the session.
>
> 2b. Add the PasswordChangeRequired field to 
> /redfish/v1/AccountManager/Accounts/<account>.  Does this require 
> D-Bus changes?
   I understand that PasswordChangeRequired filed is supported by the 
redfish in the account schema, but how it would be useful.
   Suppose we have the implementation for the above then how does user 
knows that his password has been expired.
   He has to create the session which should tell that his password has 
been expired.

  2c. Tweak the authority model to handle privilege ConfigureSelf which 
applies only to *your* Session or Account and is intended to encompass 
all the privileges needed change your own expired password.  I am 
pursuing this question in private Redfish forums (issue 1986).

My suggestion is to allow the session to be created with the expired 
password and the session with expired password only allow to change the 
password for that account.
Other redfish interfaces should be restricted to access.
>
> 2d. Tweak the authority for the 
> /redfish/v1/AccountManager/Accounts/<account> "Password" property as a 
> Redfish "property override".  The Password property needs to have a 
> different authority than the other ManagerAccount properties in that 
> same account.
Why do we need property override for the same? User can change it's own 
user configuration eg password etc.  why different authority for the 
password?
Seems I am missing something here.
>
> 3. Enhance phosphor-webui to handle the expired password dialog at 
> login.  This will use the enhanced Redfish APIs. See 
> https://github.com/ibm-openbmc/dev/issues/1048
>
> 4. Enhance Dropbear SSH so a user can change their expired password.  
> See 
> https://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2016q2/001895.html 
> This piece is optional, but I would like this to be available. The 
> alternative is to use the OpenSSH server instead of Dropbear. The 
> right place to do this piece is in Dropbear.
What about IPMI? As you mentioned we need to support this through IPMI 
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/23849/3/designs/expired-password.md#98
How does user knows that his password has been expired via inband access 
IPMI?
>
> - Joseph
>
Ratan