All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joseph Reynolds <jrey@linux.ibm.com>
To: Patrick Williams <patrick@stwcx.xyz>,
	Brad Bishop <bradleyb@fuzziesquirrel.com>
Cc: openbmc <openbmc@lists.ozlabs.org>
Subject: Re: Request new repo for IBM-specific code
Date: Thu, 29 Apr 2021 16:09:58 -0500	[thread overview]
Message-ID: <2b7c9c78-37c5-5964-5f4c-d07fadf3590a@linux.ibm.com> (raw)
In-Reply-To: <YEZwz6C5uGk8Vobs@heinlein>

On 3/8/21 12:45 PM, Patrick Williams wrote:
> On Sat, Mar 06, 2021 at 10:09:36PM -0600, Joseph Reynolds wrote:
>> On 3/5/21 1:15 PM, Patrick Williams wrote:
>>> On Thu, Mar 04, 2021 at 09:14:47PM -0600, Joseph Reynolds wrote:
>>> My first reading of what is there, I'm not sure why typical certificate
>>> based authentication couldn't solve your needs (but I'm just guessing
>>> what your needs are).  It seems like you have a root-authority (IBM), a
>>> a daily expiring certificate, and some fields in the certificate you
>>> want to confirm (ex. serial number).  I've seen other production-level
>>> systems doing similar for SSH/HTTPS without additional PAM modules.
>> Our service team requires password based authentication.  Period. And
>> they don't like the idea of having to generate a certificate/password
>> pair for each service call.  But certificates offer the best technology
>> we have to solve the access problem.  And we are not yet prepared to go
>> to a certificate-only solution. ... So this is where we are at.
>>
>>>> Note the [pam-ipmi modules][] are scoped to the OpenBMC project because
>>>> the IPMI implementation is shared by all of OpenBMC.  By comparison, the
>>>> proposed ibm-pam-acf module is intended only for IBM Enterprise
>>>> systems.  The intended implementation is based on standard cryptography
>>>> techniques and could be developed into a general authentication
>>>> solution, but the ACF is specific to IBM in terms of its exact format
>>>> and content, and I expect it will only be used by IBM and its partners.
>>> Are you planning to open up the tools necessary to create these ACFs?
>> No, I hadn't been, but good idea!  We have prototype tools to generate
>> and read the ACF.  They should be useful to our test team.
>> There should be nothing secret in the code.  ("The only secret is the
>> private key.")  I'll check with my security team.
> My two concerns about hosting a repository for this are:
>     1. Is it actually a secure method?
>     2. Is it [potentially] useful to anyone else?
>
> WRT, #1, I think we need more details to make an assessment.
>
> For #2 I think there is some unsettled debate around "what do we do
> about code that is only ever going to be useful to one company"?
> Opening up the tools would at least make it possible that someone else
> could find this useful.  I think the proposed "Repository Review Board"
> might work on better guidance otherwise.
>
> Beyond that, I just have the normal "is this the right way to be doing
> this" questions.  You've answered that somewhat with the Certs.  I may
> disagree with it, but you obviously know your support team better than I
> do.
>
> I recommended some SSH support for certificates before.  Based on your
> ask for password-based authentiation, I would suggest looking into
> pam_2fa[1] as a potential implementation as well.
...snip...

Let's restart this thread from where we left off.  I am working on an 
IBM-specific design to explain the BMC portions of the IBM ACF design to 
the OpenBMC community.

For item 1 ("is the ACF design a secure method"), we discussed an 
abbreviated threat model in this email thread.  From the service 
organizations point of view, it only allows authorized service reps into 
the service account.  And from the BMC admin's point of view, they can 
either lock out or authorize the service user via how they handle the 
ACFm but they don't know the password so they cannot login to the 
service account.
The ACF features including its digital signature, matching system serial 
number, and expiration date -- all of these limit which ACFs a BMC will 
accept.  The new Linux-PAM module login is a straightforward decoding 
and validation of the ACF, and then checking the password hash.  We 
discussed using pam_2fa in this email thread, and I believe it only 
trades the complexity of a PAM module (which I regard as 
straightforward) for the complexity of a REST server.

For item 2 ("is it useful to anyone else"), the answer is no.  This will 
ever only be useful to IBM and to vendors who clone OpenPOWER systems 
including IBM's approach to service account access.

So ... does the GitHub OpenBMC organization host vendor specific repos 
(perhaps github.com/openbmc/ibm-misc), or does the source code go 
somewhere else (such as IBM's public fork in 
github.com/ibm-openbmc/pam-ibm-acf)?

- Joseph


  parent reply	other threads:[~2021-04-29 21:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-05  3:14 Request new repo for IBM-specific code Joseph Reynolds
2021-03-05 19:15 ` Patrick Williams
2021-03-05 22:05   ` Patrick Williams
2021-03-07  4:09   ` Joseph Reynolds
2021-03-08 18:45     ` Patrick Williams
2021-03-08 20:30       ` Request new repo for IBM-specific code - pam_2fa discussion Joseph Reynolds
2021-03-08 22:41         ` Patrick Williams
2021-03-09 17:43           ` Joseph Reynolds
2021-04-29 21:09       ` Joseph Reynolds [this message]
2021-04-29 21:24         ` Request new repo for IBM-specific code Ed Tanous
2021-04-30  0:47           ` Joseph Reynolds
2021-04-30 13:29         ` Patrick Williams
2021-05-01  5:30           ` Request new repo for IBM-specific code: ibm-acf Joseph Reynolds
2021-05-02 23:46             ` Andrew Jeffery
2021-05-03  1:37               ` Andrew Jeffery
2021-05-03 16:21         ` Request new repo for IBM-specific code Ed Tanous
2021-03-08 16:03 ` Ed Tanous
2021-03-08 17:30   ` Joseph Reynolds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2b7c9c78-37c5-5964-5f4c-d07fadf3590a@linux.ibm.com \
    --to=jrey@linux.ibm.com \
    --cc=bradleyb@fuzziesquirrel.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=patrick@stwcx.xyz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.