Initial expired passwords - low level designs

Fri Aug 23 08:49:04 AEST 2019

On 8/21/19 10:19 PM, Ratan Gupta wrote:
> 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.

I understand.  Perhaps we do not need this new field.  Let's drop this 
change.

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

That was the same as my idea.  This is also the same idea as the Redfish 
PasswordChangeRequired spec.  With that spec, the flow to change your 
expired password is:
1. User signs into Redfish with an expired password.
2. Redfish creates a Session which has the a @Message.ExtendedInfo 
object in the response containing the PasswordChangeRequired message. 
That's how the user knows their password needs to be changed.  The 
session carries only the Redfish ConfigureSelf privilege, which 
restricts the session to only changing that user's password.
3. The user PATCHes the new password into their Account.
4. The user DELETEs their Session.

Any other attempted use of that session would get HTTP response code 403 
with a body that includes a @Message.ExtendedInfoobject containing the 
PasswordChangeRequired message from the Base Message Registry.

Most of the detail above is directly from the spec version 1.7.0, 
section 13.2.6.1.

The details about using the Redfish ConfigureSelf privilege are given in 
the Redfish Schema Supplement, version 2019.1a, 
https://www.dmtf.org/sites/default/files/standards/documents/DSP0268_2019.1a.pdf

The detail about having a property override for the ManagerAccount 
Password property is given in the Redfish privilege registry (such as 
https://redfish.dmtf.org/schemas/v1/PrivilegeRegistry.v1_1_3.json) 
although the current spec is less clear on this topic.

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

This is following the Redfish spec (override for the ManagerAccount 
Password property) and the example in section 13.2.10.5 ("Property 
override example") of the Redfish spec 1.7.0.

The idea is that you must have the Redfish ConfigureUsers privilege to 
PATCH any account data, and the ConfigureSelf privilege only lets a user 
PATCH their own Password (and no other properties of their own 
account).  That's the definition of a Redfish property override.

>>
>> 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?

I don't know so much about IPMI.  I was told the IPMI RAKP+ spec does 
not allow access from an account which has an expired password.  At this 
time, I have no way to know  the password is expired via the IPMI 
interface.  Is there a way to do it?

If you have unauthenticated access to IPMI, I think you could do 
something like: `ipmitool user set password 1` to change the password.  
I'll add this test case to my design review.

- Joseph

>>
>> - Joseph
>>
> Ratan
>