Proposal: delete BMCWeb sessions after some kinds of account changes

[Joseph Reynolds]

On 2/21/20 6:45 AM, Alexander Tereschenko wrote:
> On 17-Feb-20 23:10, Joseph Reynolds wrote:
>> This proposal is to enhance BMCWeb to terminate login session that 
>> are associated with accounts that have incompatible changes.  I 
>> understand this practice is allowed Redfish and recommended by OWASP.
>>
> This makes sense to me, with one specific note - see below

Good.  I hadn't thought through any of the specific cases.  Some ideas:
1. password becomes expired (for any reason, for example due to password 
aging (which is not implemented in OpenBMC)) ==> the 
PasswordChangeRequired property becomes true, with its restrictions.
2. password becomes unexpired (because a new password was successfully 
set) ==> currently the session remains valid <-- Redfish specifically 
allows that behavior.  On the other hand, OWASP recommends deleting the 
session even in this case.
3. The account itself is disabled, expired, or deleted.  ==> The session 
gets deleted.
4. The account is renamed ==> The session gets deleted.

Hey George, are you getting some ideas for test cases here?  :-)

>
>> - The [proposed][] ExpiredPassword D-Bus property and the 
>> PasswordChangeRequired Redfish properties set to True.  Sessions 
>> where this property is True are needed for a user to change their own 
>> password.
>
> While not terminating these sessions (which certainly makes sense), 
> should we restrict them to only allow for password change action 
> starting immediately after that flag is set? I'm not sure how it works 
> now.

Yes.  To clarify the wording: When an account's password changes to 
expired aka "PasswordChangeRequired", in-flight operations can complete, 
but new operations (including operations from an valid login session) 
should be restricted by the PasswordChangeRequired requirements (which 
restrict the session to the operations required to change the account 
password).

My proposed ExpiredPassword D-Bus property design ( 
https://lists.ozlabs.org/pipermail/openbmc/2020-February/020554.html) 
would make the statement above become true.  I am currently working on 
the first part of the implementation (the D-Bus portion), with the 
BMCWeb portion to follow.
That same design would also make the converse true: Successfully setting 
a new password would remove the PasswordChangeRequired condition; this 
would allow the session's usual privileges to take effect.

Now let me get back to that....

- Joseph

>
> regards,
> Alexander
>