Request new repo for IBM-specific code - pam_2fa discussion

[Joseph Reynolds]

On 3/8/21 4:41 PM, Patrick Williams wrote:
> On Mon, Mar 08, 2021 at 02:30:26PM -0600, Joseph Reynolds wrote:
>> Patrick, thanks for that.  I was unaware of the pam_2fa project.  I
>> agree this could a be a good way for BMCs to get 2FA.
>>
>> However, as I tried to state in this email thread, the IBM firmware
>> service organization requires that all credentials be brought onto the
>> work site because some sites have no way to communicate with an external
>> server.  That is, once you are on a customer site, you might not be able
>> to call into IBM (or even have access to a phone).  Although this is not
>> typical, I don't think it is unique to IBM.  What is done other secure
>> installations?
> I might have poorly explained my thought process before.  I know
> *normal* 2FA requires remote access to the 2FA server.  The PAM_2FA
> allows configuration of the URL and there is no reason why the URL
> cannot be a localhost implementation of the 2FA protocol.  All the
> protocol does is POST to the URL and make a decision based on the HTTP
> return code.
>
> Proposal:
>      * Use 'pam_2fa' using Yubikey protocol to point at a 'localhost' URL.
>      * Implement Yubikey 2FA protocol (described in pam_2fa
>        documentation) in a small daemon on the BMC, specific for ACF
>        certificates.
>          - 2FA request will get the ACF password.
>          - ACF daemon hashes password, checks with installed certificate
>            and returns 4xx/2xx codes as appropriate.
>      * Set PAM config to use 'pam_2fa' (pointed at localhost) for IBM
>        service users.

Thanks again.  I see it now.  This could work for IBM ACFs.

Your proposal is:
Instead of writing a new Linux-PAM module which checks the password with 
the ACF, this proposal uses pam_2fa.so together with a new BMC-hosted 
HTTPS server (implemented as a new systemd service) which checks the 
password with the ACF.  Instead of putting the checks into my new 
proposed Linux-PAM module, I would put them into the HTTPS REST API server.

I'm not sure what advantage this would give.  It seems like this gives 
me a tested PAM module in exchange for implementing a REST API server.  
I'm not sure I want to make that trade.  The Linux-PAM coding aspects of 
my proposed module are well-understood and straightforward.

> In summary, the service accounts can have a static primary password AND
> an ACF-secured secondary password which is checked with the standard 2FA
> protocol.
>
>> The IBM ACF design in terms of 2FA is:
> ...
>> 2. The ACF has no secrets (other than the password hash stored within
>> it) and can be installed onto the BMC by the admin or the service rep.
> Doesn't the service user have access you're not expecting the 'admin' to
> be able to have on your machines?  How do you ensure a compromised ACF
> cannot be replayed onto another machine?  With admin-level access it is
> fairly trivial to fake out the serial number.

Yes, on IBM Enterprise machines, service access is a superset of admin 
access.  In particular, the interface to change an existing machine 
serial number requires service access.  However, it remains possible for 
a machine owner to use shenanigans to change serial numbers.  This, plus 
the admin's ability to record the service user password and to change 
the BMC's TOD would give them the ability to re-use an ACF.

> I might be misunderstanding something with "... or ther service rep".
> It seems like there is a gap in how the service rep would install
> something when the ACF is what gives them permissions to do the install?

You are correct.  I didn't explain scenarios.

First, note the proposed REST API to install the ACF requires admin 
authority.  There are multiple alternate workflows:
1. A security conscious system owner would have the admin install the 
ACF immediately before service and remove it immediately afterward.  And 
probably look over the service agent's shoulder.
2. A trusting system owner would share admin access with the service 
agent who would install and remove the ACF on behalf of the owner.
3. A forgetful system owner would not have admin access (having lost the 
password).  In this case the service agent asserts physical presence to 
open a time window in which they could upload the ACF without 
authentication or authority needed.

Joseph