Security Working Group meeting - this Wednesday February 19

Security Working Group meeting - this Wednesday February 19

[Joseph Reynolds]

This is a reminder of the OpenBMC Security Working Group meeting 
scheduled for this Wednesday February 19 at 10:00am PDT.

We'll discuss current development items, and anything else that comes up.

Ratan intends to participate and has requested that we cover the 
following two items first:
(A) service discovery direction, (B) using pam_abl

The current topics:

1. (Joseph): Is OpenBMC affected by the Chrome browser’s SameSite cookie 
changes 
(https://blog.chromium.org/2020/02/samesite-cookie-changes-in-february.html)? 
Do we want to enhance BMCWeb 
(https://github.com/openbmc/bmcweb/blob/master/include/token_authorization_middleware.hpp#L430) 
to create cookies with SameSite=None; Secure when 
BMCWEB_INSECURE_DISABLE_XSS_PREVENTION is also used, to allow the BMC to 
be used by the Chrome browser.  Perhaps by default BMCWeb should 
generate cookies with SameSite=Strict?  


2. (Joseph, follow up to agenda item 3 from 2020-02-05): Redfish 
Privilege updates: 
https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/28881 and 
https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/28878  Update Feb 
11: See 
https://redfishforum.com/thread/281/manageraccountcollection-change-allows-account-enumeration 
clarified the intention to NOT enumerate all accounts (unless you are 
the admin)


3. (email) FYA.  BMC aggregator - includes a security topic. 
https://lists.ozlabs.org/pipermail/openbmc/2020-February/020433.html 


4. (email) FYA - BMC Secure Boot / U-Boot - use dm-verity or alternate? 
https://lists.ozlabs.org/pipermail/openbmc/2020-February/020452.html 


5. Redfish forum question: Direction for channel based restrictions - 
https://redfishforum.com/thread/279/channel-privilege-support-direction-redfish 


6. (Bruce via email):  BMCWeb Cert valid for 10 years - 
https://lists.ozlabs.org/pipermail/openbmc/2020-February/020488.html 


7. (Joseph / James / Richard email): Rate limiting, use pam_abl - 
https://lists.ozlabs.org/pipermail/openbmc/2020-February/020430.html 


8. (Joseph via email): New Redfish roles ServiceRep & OemRep - 
https://lists.ozlabs.org/pipermail/openbmc/2020-February/020540.html 


9. (Joseph email): Implement the Redfish PasswordChangeRequired property 
  https://lists.ozlabs.org/pipermail/openbmc/2020-February/020554.html 


10. (Joseph email): delete BMCWeb sessions after some kinds of account 
changes
 
https://lists.ozlabs.org/pipermail/openbmc/2020-February/020555.html 




Access, agenda, and notes are in the wiki:

https://github.com/openbmc/openbmc/wiki/Security-working-group

- Joseph

Re: Security Working Group meeting - this Wednesday February 19 - summary results

[Joseph Reynolds]

On 2/17/20 4:29 PM, Joseph Reynolds wrote:
> This is a reminder of the OpenBMC Security Working Group meeting 
> scheduled for this Wednesday February 19 at 10:00am PDT.

This meeting was held.  Only the first 7 items were discussed.  The 
remaining items stay on the list for next time (Wednesday March 4).

>
> We'll discuss current development items, and anything else that comes up.
>
> Ratan intends to participate and has requested that we cover the 
> following two items first:
> (A) service discovery direction, (B) using pam_abl
>
> The current topics:
>
> 1. (Joseph): Is OpenBMC affected by the Chrome browser’s SameSite 
> cookie changes 
> (https://blog.chromium.org/2020/02/samesite-cookie-changes-in-february.html)? 
> Do we want to enhance BMCWeb 
> (https://github.com/openbmc/bmcweb/blob/master/include/token_authorization_middleware.hpp#L430) 
> to create cookies with SameSite=None; Secure when 
> BMCWEB_INSECURE_DISABLE_XSS_PREVENTION is also used, to allow the BMC 
> to be used by the Chrome browser.  Perhaps by default BMCWeb should 
> generate cookies with SameSite=Strict?  

>
Joseph will create bmcweb issue for this.


> 2. (Joseph, follow up to agenda item 3 from 2020-02-05): Redfish 
> Privilege updates: 
> https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/28881 and 
> https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/28878 Update Feb 
> 11: See 
> https://redfishforum.com/thread/281/manageraccountcollection-change-allows-account-enumeration 
> clarified the intention to NOT enumerate all accounts (unless you are 
> the admin)


Consensus was to leave OpenBMC as-is (only admin can enumerate users) 
until Redfish releases a new spec.
>
> 3. (email) FYA.  BMC aggregator - includes a security topic. 
> https://lists.ozlabs.org/pipermail/openbmc/2020-February/020433.html 



Nancy plans to follow up.

>
> 4. (email) FYA - BMC Secure Boot / U-Boot - use dm-verity or 
> alternate? 
> https://lists.ozlabs.org/pipermail/openbmc/2020-February/020452.html 


Need BMC threat model to understand what threats dm-verity protects 
against.  Note that integrity protection is a defense in depth against 
an attacker who can run code on the BMC which writes to the BMC’s file 
system.

Is the BMC filesystem writeable?  ANS: It uses read-write overlay 
filesystem on /etc.  Idea: Could discontinue using overlays and use soft 
links to fs on read-write partition

>
> 5. Redfish forum question: Direction for channel based restrictions - 
> https://redfishforum.com/thread/279/channel-privilege-support-direction-redfish 


Redfish direction is to NOT change Role based on channel, and suggests 
implementations can offer a different set of accounts based on ingress 
channel (for example, based on which ethernet device (eth0, eth1, etc) 
the accessed the BMC).

OpenBMC community may have multiple use cases for a feature like this. 
Either the mgmt network or host may be more secure, and the other is 
less secure.

Idea: expose the list of channels within OpenBMC, and allow 
Account-Channel associations.  For example, an interface to allow 
“admin2” to access the BMC only from “eth0” or “eth1” but not “eth2”.


>
> 6. (Bruce via email):  BMCWeb Cert valid for 10 years - 
> https://lists.ozlabs.org/pipermail/openbmc/2020-February/020488.html 


Change BMCweb’s default self-signed cert to a maximum of 825 days.  
Recommend 30 days.

When this is done, if BMCWeb generates a self-signed cert, and it is not 
replaced, and the BMC’s time is sane, then browsers that connect to 
BMCWeb will start to complain after 30 days.

The recovery is: The BMC admin should install a valid BMCWeb site 
identity cert, then clients can re-connect to the BMC. (This will serve 
the updated cert and make the browser happy.)

The “BMC Admin guide” should talk about installing your own cert.

See docs here: https://github.com/openbmc/bmcweb/#configuration

Ass code here: 
https://github.com/openbmc/bmcweb/blob/91243c3b28b1df66e682f5a3ee96341fdc516b5a/include/ssl_key_handler.hpp#L205

Will there be a warning for the BMC admin (that the BMCWeb site cert 
will expire soon)?  (And don’t rely on a warning from the browser itself.)


>
> 7. (Joseph / James / Richard email): Rate limiting, use pam_abl - 
> https://lists.ozlabs.org/pipermail/openbmc/2020-February/020430.html 


There was concern about any account lockout mechanism locking out 
legitimate users; throttling is safer.

Next step is to design how this would be used.


>
> 8. (Joseph via email): New Redfish roles ServiceRep & OemRep - 
> https://lists.ozlabs.org/pipermail/openbmc/2020-February/020540.html 

>
> 9. (Joseph email): Implement the Redfish PasswordChangeRequired 
> property 
>  https://lists.ozlabs.org/pipermail/openbmc/2020-February/020554.html 

>
> 10. (Joseph email): delete BMCWeb sessions after some kinds of account 
> changes
 
> https://lists.ozlabs.org/pipermail/openbmc/2020-February/020555.html 


>

These item (8-10) were not address due to lack of time.  They remain for 
next time.

>
> Access, agenda, and notes are in the wiki:
>
> https://github.com/openbmc/openbmc/wiki/Security-working-group
>
> - Joseph
>
>

Re: Security Working Group meeting - this Wednesday February 19 - summary results

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1902 bytes --]

On Wed, Feb 19, 2020 at 05:05:09PM -0600, Joseph Reynolds wrote:
> On 2/17/20 4:29 PM, Joseph Reynolds wrote:

> > 6. (Bruce via email):  BMCWeb Cert valid for 10 years -
> > https://lists.ozlabs.org/pipermail/openbmc/2020-February/020488.html 

> 
> Change BMCweb’s default self-signed cert to a maximum of 825 days. 
> Recommend 30 days.
> 
> When this is done, if BMCWeb generates a self-signed cert, and it is not
> replaced, and the BMC’s time is sane, then browsers that connect to BMCWeb
> will start to complain after 30 days.
> 
> The recovery is: The BMC admin should install a valid BMCWeb site identity
> cert, then clients can re-connect to the BMC. (This will serve the updated
> cert and make the browser happy.)
> 
> The “BMC Admin guide” should talk about installing your own cert.
> 
> See docs here: https://github.com/openbmc/bmcweb/#configuration
> 
> Ass code here: https://github.com/openbmc/bmcweb/blob/91243c3b28b1df66e682f5a3ee96341fdc516b5a/include/ssl_key_handler.hpp#L205
> 
> Will there be a warning for the BMC admin (that the BMCWeb site cert will
> expire soon)?  (And don’t rely on a warning from the browser itself.)

If I read this correctly, the side-effect of this proposed change is:

   - If I leave my BMC running for 30 days without it crashing, the
     certificate it presents will have become expired and no longer
     valid.

Is that true?  Can we put something into bmcweb to detect its own
certificate has expired and generate a new one?

I know self-signed certs aren't great, but the minute I have more than 6
systems I'm not going to want to follow some "BMC Admin Guide" to update
certificates by hand.  So we're effectively forcing everyone to develop
some kind of certificate management infrastructure, without providing
(or pointing to an existing) implementation.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Security Working Group meeting - this Wednesday February 19 - summary results

[Alexander Tereschenko]

On 20-Feb-20 17:26, Patrick Williams wrote:
> Can we put something into bmcweb to detect its own
> certificate has expired and generate a new one?

The idea here is to discourage any prolonged use of the default 
self-signed certs at all, as they don't provide full protection from 
MitM attacks. That's why the 30 days validity period was suggested 
(compared to current 10 years) and discussed during the meeting. Adding 
an auto-regeneration feature would be going directly against that idea, 
so I personally wouldn't vote for that.

> I know self-signed certs aren't great, but the minute I have more than 6
> systems I'm not going to want to follow some "BMC Admin Guide" to update
> certificates by hand.  So we're effectively forcing everyone to develop
> some kind of certificate management infrastructure, without providing
> (or pointing to an existing) implementation.
I'd say that in such context, you'd be using one of the configuration 
management systems (Puppet/Chef/Salt/Ansible/homegrown scripts/whatnot) 
anyway, as that's a standard system administration BKM, so IMHO that's a 
reasonable assumption at the OpenBMC project end that it's not going to 
add any noticeable burden for BMC admins.

Re: Security Working Group meeting - this Wednesday February 19 - summary results

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 2553 bytes --]

On Fri, Feb 21, 2020 at 01:19:25PM +0100, Alexander Tereschenko wrote:
> On 20-Feb-20 17:26, Patrick Williams wrote:
> > Can we put something into bmcweb to detect its own
> > certificate has expired and generate a new one?
> 
> The idea here is to discourage any prolonged use of the default self-signed
> certs at all, as they don't provide full protection from MitM attacks.
> That's why the 30 days validity period was suggested (compared to current 10
> years) and discussed during the meeting. Adding an auto-regeneration feature
> would be going directly against that idea, so I personally wouldn't vote for
> that.

To me, if bmcweb is handing out an expired self-signed certificate that
is a bug.  I don't think we should be so heavy-handed to decide for
others what "secure" means.  We can certainly propose best practices but
we should not force specific behavior.

I'm not suggesting that real certs aren't better than self-signed ones,
but some people have a well-isolated management network in a data center
behind locked doors.  They might decide that the likelihood of MitM attack
there isn't serious enough to devote engineering resources on a
certificate distribution scheme. (*)

We should keep in mind that part of the original motivation for this
project, and what keeps certain companies that don't market
general-purpose servers involved in it, is that they weren't satisfied
with the constraints being placed on them by the standard offering in
the industry.  If we become too heavy-handed here, we also lose that
advantage.

> > I know self-signed certs aren't great, but the minute I have more than 6
> > systems I'm not going to want to follow some "BMC Admin Guide" to update
> > certificates by hand.  So we're effectively forcing everyone to develop
> > some kind of certificate management infrastructure, without providing
> > (or pointing to an existing) implementation.
> I'd say that in such context, you'd be using one of the configuration
> management systems (Puppet/Chef/Salt/Ansible/homegrown scripts/whatnot)
> anyway, as that's a standard system administration BKM, so IMHO that's a
> reasonable assumption at the OpenBMC project end that it's not going to add
> any noticeable burden for BMC admins.

Fair.  But again, others might not feel that is a high enough value
problem to devote engineering resources to solve.

(*) Please don't read this as an implication into how my current
    employer's management network is or is not designed.
-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

RE: Security Working Group meeting - this Wednesday February 19 - summary results

[Bruce Mitchell]

> -----Original Message-----
> From: openbmc [mailto:openbmc-
> bounces+bruce_mitchell=phoenix.com@lists.ozlabs.org] On Behalf Of
> Patrick Williams
> Sent: Friday, February 21, 2020 12:10
> To: Alexander Tereschenko
> Cc: openbmc@lists.ozlabs.org
> Subject: Re: Security Working Group meeting - this Wednesday February
> 19 - summary results
> 
> On Fri, Feb 21, 2020 at 01:19:25PM +0100, Alexander Tereschenko wrote:
> > On 20-Feb-20 17:26, Patrick Williams wrote:
> > > Can we put something into bmcweb to detect its own certificate has
> > > expired and generate a new one?
> >
> > The idea here is to discourage any prolonged use of the default
> self-signed
> > certs at all, as they don't provide full protection from MitM attacks.
> > That's why the 30 days validity period was suggested (compared to
> current 10
> > years) and discussed during the meeting. Adding an auto-regeneration
> feature
> > would be going directly against that idea, so I personally wouldn't
> vote for
> > that.
> 
> To me, if bmcweb is handing out an expired self-signed certificate that is
> a bug.  I don't think we should be so heavy-handed to decide for others
> what "secure" means.  We can certainly propose best practices but we
> should not force specific behavior.
> 
> I'm not suggesting that real certs aren't better than self-signed ones, but
> some people have a well-isolated management network in a data center
> behind locked doors.  They might decide that the likelihood of MitM
> attack there isn't serious enough to devote engineering resources on a
> certificate distribution scheme. (*)
> 
> We should keep in mind that part of the original motivation for this
> project, and what keeps certain companies that don't market general-
> purpose servers involved in it, is that they weren't satisfied with the
> constraints being placed on them by the standard offering in the industry.
> If we become too heavy-handed here, we also lose that advantage.
> 

I do not believe that the BMC's self-generated self-signed certificate should
be beyond what web browsers will accept (or in the near future).  If the customer
wants to install their own self-signed certificate (i.e. not from the BMC) then that
is their issue and can do what they want on  their own self-signed certificate.

> > > I know self-signed certs aren't great, but the minute I have more
> than 6
> > > systems I'm not going to want to follow some "BMC Admin Guide" to
> update
> > > certificates by hand.  So we're effectively forcing everyone to
> develop
> > > some kind of certificate management infrastructure, without
> providing
> > > (or pointing to an existing) implementation.
> > I'd say that in such context, you'd be using one of the configuration
> > management systems (Puppet/Chef/Salt/Ansible/homegrown
> scripts/whatnot)
> > anyway, as that's a standard system administration BKM, so IMHO that's
> a
> > reasonable assumption at the OpenBMC project end that it's not going
> to add
> > any noticeable burden for BMC admins.
> 
> Fair.  But again, others might not feel that is a high enough value
> problem to devote engineering resources to solve.
> 
> (*) Please don't read this as an implication into how my current
>     employer's management network is or is not designed.
> --
> Patrick Williams

Re: Security Working Group meeting - this Wednesday February 19 - summary results

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]

On Fri, Feb 21, 2020 at 08:21:27PM +0000, Bruce Mitchell wrote:

Hi Bruce,

> I do not believe that the BMC's self-generated self-signed certificate should
> be beyond what web browsers will accept (or in the near future).  If the customer
> wants to install their own self-signed certificate (i.e. not from the BMC) then that
> is their issue and can do what they want on  their own self-signed certificate.

I think this is in reference to your original concern about the
certificate being 800+ days?  If so, I agree we should shorten if that is
more appropriate from a browser perspective.

My only concern is that it appears we're generating the certificate once
and if the bmcweb daemon stays up longer than that expiration time, we
end up serving out an expired certificate.  Unfortunately this isn't
something you can even observe until 30 days or so in the future.

[ I remember once having a ~40 day bug in a product because someone
  stored milliseconds in a 32 bit integer.  It can be a real pain to debug
  something that only happens when you don't touch it for a month. ]

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Security Working Group meeting - this Wednesday February 19 - summary results

[James Feist]

On 2/21/20 12:21 PM, Bruce Mitchell wrote:
> 
> 
>> -----Original Message-----
>> From: openbmc [mailto:openbmc-
>> bounces+bruce_mitchell=phoenix.com@lists.ozlabs.org] On Behalf Of
>> Patrick Williams
>> Sent: Friday, February 21, 2020 12:10
>> To: Alexander Tereschenko
>> Cc: openbmc@lists.ozlabs.org
>> Subject: Re: Security Working Group meeting - this Wednesday February
>> 19 - summary results
>>
>> On Fri, Feb 21, 2020 at 01:19:25PM +0100, Alexander Tereschenko wrote:
>>> On 20-Feb-20 17:26, Patrick Williams wrote:
>>>> Can we put something into bmcweb to detect its own certificate has
>>>> expired and generate a new one?
>>>
>>> The idea here is to discourage any prolonged use of the default
>> self-signed
>>> certs at all, as they don't provide full protection from MitM attacks.
>>> That's why the 30 days validity period was suggested (compared to
>> current 10
>>> years) and discussed during the meeting. Adding an auto-regeneration
>> feature
>>> would be going directly against that idea, so I personally wouldn't
>> vote for
>>> that.
>>
>> To me, if bmcweb is handing out an expired self-signed certificate that is
>> a bug.  I don't think we should be so heavy-handed to decide for others
>> what "secure" means.  We can certainly propose best practices but we
>> should not force specific behavior.
>>
>> I'm not suggesting that real certs aren't better than self-signed ones, but
>> some people have a well-isolated management network in a data center
>> behind locked doors.  They might decide that the likelihood of MitM
>> attack there isn't serious enough to devote engineering resources on a
>> certificate distribution scheme. (*)
>>
>> We should keep in mind that part of the original motivation for this
>> project, and what keeps certain companies that don't market general-
>> purpose servers involved in it, is that they weren't satisfied with the
>> constraints being placed on them by the standard offering in the industry.
>> If we become too heavy-handed here, we also lose that advantage.
>>
> 
> I do not believe that the BMC's self-generated self-signed certificate should
> be beyond what web browsers will accept (or in the near future).  If the customer
> wants to install their own self-signed certificate (i.e. not from the BMC) then that
> is their issue and can do what they want on  their own self-signed certificate.
> 

I think the original motivation of 10 years was something above the 
average support cycle of a server, so on first boot the user has 
something they can use to login to the server with. That being said, if 
the browser wont let you in, that is obviously more important. 30 days 
seems a bit too strict considering shipping / unpacking times make it 
likely you'll have an expired certificate upon arrival. But if we can't 
come to an agreement, we can always make this configurable.


>>>> I know self-signed certs aren't great, but the minute I have more
>> than 6
>>>> systems I'm not going to want to follow some "BMC Admin Guide" to
>> update
>>>> certificates by hand.  So we're effectively forcing everyone to
>> develop
>>>> some kind of certificate management infrastructure, without
>> providing
>>>> (or pointing to an existing) implementation.
>>> I'd say that in such context, you'd be using one of the configuration
>>> management systems (Puppet/Chef/Salt/Ansible/homegrown
>> scripts/whatnot)
>>> anyway, as that's a standard system administration BKM, so IMHO that's
>> a
>>> reasonable assumption at the OpenBMC project end that it's not going
>> to add
>>> any noticeable burden for BMC admins.
>>
>> Fair.  But again, others might not feel that is a high enough value
>> problem to devote engineering resources to solve.
>>
>> (*) Please don't read this as an implication into how my current
>>      employer's management network is or is not designed.
>> --
>> Patrick Williams
> 

Re: Security Working Group meeting - this Wednesday February 19 - summary results

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 3687 bytes --]


Patrick Williams <patrick@stwcx.xyz> wrote:
    >> > 6. (Bruce via email):  BMCWeb Cert valid for 10 years -
    >> > https://lists.ozlabs.org/pipermail/openbmc/2020-February/020488.html 

    >>
    >> Change BMCweb’s default self-signed cert to a maximum of 825 days. 
    >> Recommend 30 days.
    >>
    >> When this is done, if BMCWeb generates a self-signed cert, and it is not
    >> replaced, and the BMC’s time is sane, then browsers that connect to BMCWeb
    >> will start to complain after 30 days.
    >>
    >> The recovery is: The BMC admin should install a valid BMCWeb site identity
    >> cert, then clients can re-connect to the BMC. (This will serve the updated
    >> cert and make the browser happy.)
    >>
    >> The “BMC Admin guide” should talk about installing your own cert.
    >>
    >> See docs here: https://github.com/openbmc/bmcweb/#configuration
    >>
    >> Ass code here: https://github.com/openbmc/bmcweb/blob/91243c3b28b1df66e682f5a3ee96341fdc516b5a/include/ssl_key_handler.hpp#L205
    >>
    >> Will there be a warning for the BMC admin (that the BMCWeb site cert will
    >> expire soon)?  (And don’t rely on a warning from the browser itself.)

    > If I read this correctly, the side-effect of this proposed change is:

    > - If I leave my BMC running for 30 days without it crashing, the
    > certificate it presents will have become expired and no longer
    > valid.

My reading of the code says is that in ensureOpensslKeyPresentAndValid() that
if the certificate is invalid, according to X509_verify_cert() that a new
self-signed certificate will be generated.
So, I agree that if the BMC does not reboot within the self-signed
certificate time, then it will expire, and this will be surprising.

{A system could *easily* get turned on within a group of several hundred, and
nobody gets around to noticing that it wasn't cabled correctly for 30 days
until one gets to the end of the onboarding process and asks why we bought
746 servers, and only onboarded 745 machines.}

So, this is probably rather wrong to limit to 30 days.

a) Only a self-signed certificate that was locally generated should be replaced.
   Replacing an administrator installed certificate because the clock was wrong
   is most likely wrong.

b) As long as we have this logic, we might as well do this check before
   accepting any HTTPS connection, perhaps with a do this at most once a day
   logic.     There is no advantage of expiring a self-signed certificate
   quickly in my opinion.


The concern about the CAB rules about 825 days is probably not important for
several reasons, but if one wants to limit it to that period of time, that's
okay with me.  Changing to 30 days is not a good thing.

1) the browser is going require an exception for the certificate anyway.
   Once the self-signed certificate is pinned in the browser, keeping it for
   as long as possible is better.  Expiring after 30 days makes no sense
   here.

2) it could be that browsers will reject longer-lived certificates when
   validated by a trust anchor, but the exception likely pins whatever comes
   down, period.

3) If a BMC is any kind of vulnerable environment where certificates are
   important, then the BMC needs an automated onboarding system.
   (I have one, and I'm working on code, but it's an unfunded best effort so far)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Security Working Group meeting - this Wednesday February 19 - summary results

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 1707 bytes --]


James Feist <james.feist@linux.intel.com> wrote:
    > I think the original motivation of 10 years was something above the average
    > support cycle of a server, so on first boot the user has something they can
    > use to login to the server with.

That's not a crazy consideration to me.

    > That being said, if the browser wont let you
    > in, that is obviously more important. 30 days seems a bit too strict
    > considering shipping / unpacking times make it likely you'll have an expired
    > certificate upon arrival. But if we can't come to an agreement, we can always
    > make this configurable.

1) it would be good to clarify what browsers are really going to do.

2) it won't apply to CURL, etc. which might be used to onboard a system
   automatically.

3) you can't make it configurable, because you can't configure it if you
   can't connect :-)

825 days (27 months, so 2yr plus some wiggle room) is definitely what they
are going to for built-in trust anchors.  I'm not sure if this will apply
to trust anchors that are loaded into browsers by end users, or if that
configuration will somehow be attached to the trust anchor.

So, if 825 days is a good default, I'd make it 820 days, and after 410 days,
I'd have the self-signed certificate resigned, but not generate a new private
key.   This allows for mgmt stations to pin the public key of the BMC,
ignoring the actual certificate contents.

I will try to send a patch to do this.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Security Working Group meeting - this Wednesday February 19 - summary results

[Alexander Tereschenko]

> James Feist <james.feist@linux.intel.com> wrote:
>      > I think the original motivation of 10 years was something above the average
>      > support cycle of a server, so on first boot the user has something they can
>      > use to login to the server with.
>
> That's not a crazy consideration to me.

James, do you imply that the certificate would be generated during 
server manufacturing, not at the first boot at the "end owner's" premise?
If so, that indeed changes the perspective, I personally and I think 
everyone in our discussion during the meeting thought of the generation 
as happening at the latter moment, not the former.

>      > That being said, if the browser wont let you
>      > in, that is obviously more important. 30 days seems a bit too strict
>      > considering shipping / unpacking times make it likely you'll have an expired
>      > certificate upon arrival. But if we can't come to an agreement, we can always
>      > make this configurable.
>
> 1) it would be good to clarify what browsers are really going to do.

Indeed - especially given that the recommendation mentioned [1] is a 
CA-side one (used for _issuing_ certs) and the respective RFC section 
for X.509 [2] is unchanged - so I'd expect browsers to continue sticking 
to that. Unless, of course, someone decides to go the "let's make it 
more secure for people based on that CA/Browser forum recommendation" 
way and adds some logic that would do otherwise... However imagine how 
would that look like - the browser is at the receiving end (i.e. 
browser's user typically has no control over the cert), what does it do 
when getting such a cert? Throw a warning like "this server's 
certificate is valid for more than two years, beware" or something? 
That's bad UX, [very likely] can't be acted upon by the user anyway and 
actually FUD - the certificate is perfectly valid.

So if you want my guess, I think browsers won't do a thing about that 
and that recommendation will be enforced at the CA level only, so it is 
unlikely to affect OpenBMC users at the end of the day.

I was more concerned with the general fact that the self-signed cert we 
generate doesn't provide full protection and what _gentle_ nudges could 
be used for them to change that. In that context those 30 days looked ok 
(don't break anything, but provide additional warning for an admin).

BTW, that MiTM may not only be happening at the network level - e.g. 
admin's computer may be compromised and some process there could MitM 
the connections without tapping the network infra proper.

All in all, it actually sounds to me like we may as well be not doing 
anything here :) If admin's threat model allows for using the 
self-generated self-signed cert, early expiration may be worse UX than 
today - and if the threat model doesn't allow for that, the cert will be 
replaced anyway.

[1] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.7.pdf

[2] https://tools.ietf.org/html/rfc5280#section-4.1.2.5

Re: Security Working Group meeting - this Wednesday February 19 - summary results

[Michael Richardson]

[-- Attachment #1.1: Type: text/plain, Size: 3755 bytes --]


Alexander Tereschenko <aleksandr.v.tereschenko@linux.intel.com> wrote:
    >> James Feist <james.feist@linux.intel.com> wrote: > I think the
    >> original motivation of 10 years was something above the average >
    >> support cycle of a server, so on first boot the user has something
    >> they can > use to login to the server with.
    >>
    mcr> That's not a crazy consideration to me.

    > James, do you imply that the certificate would be generated during
    > server manufacturing, not at the first boot at the "end owner's"
    > premise?  If so, that indeed changes the perspective, I personally and
    > I think everyone in our discussion during the meeting thought of the
    > generation as happening at the latter moment, not the former.

Looking at the mechanism, it would seem that the certificate would be
generated upon first power on after the BMC was flashed.  If the VAR receives
the machine (or the shipping dock receiver), powers it on to make sure it's
not a dud, and ships it/puts-it-into-inventory, then the  30-day timer starts
then.

That's why 30 days is too short.
(If the manufacturer can put a proper IDevID into the BMC, that would be
better all around)

    mcr> 1) it would be good to clarify what browsers are really going to do.

    > Indeed - especially given that the recommendation mentioned [1] is a
    > CA-side one (used for _issuing_ certs) and the respective RFC section
    > for X.509 [2] is unchanged - so I'd expect browsers to continue
    > sticking to that. Unless, of course, someone decides to go the "let's
    > make it more secure for people based on that CA/Browser forum
    > recommendation" way and adds some logic that would do
    > otherwise...

I believe that the browsers will do this, because the CAFORUM rules would be
meaningless of nobody checked :-)

    > However imagine how would that look like - the browser is
    > at the receiving end (i.e. browser's user typically has no control over
    > the cert), what does it do when getting such a cert? Throw a warning
    > like "this server's certificate is valid for more than two years,
    > beware" or something? That's bad UX, [very likely] can't be acted upon
    > by the user anyway and actually FUD - the certificate is perfectly
    > valid.

The warning boxes are going away as fast the browser people can convince
people like us to do something different.

I have sent some emails to some contacts at Chrome and Firefox that deal with
CAForum questions, and I hope to get some guidance.

    > I was more concerned with the general fact that the self-signed cert we
    > generate doesn't provide full protection and what _gentle_ nudges could
    > be used for them to change that. In that context those 30 days looked
    > ok (don't break anything, but provide additional warning for an admin).

    > BTW, that MiTM may not only be happening at the network level -
    > e.g. admin's computer may be compromised and some process there could
    > MitM the connections without tapping the network infra proper.

Sure, there are about a hundred other issues that could occur.
The admin's out-of-warantee windows-XP desktop can be removed from the
equation if the enterprise has some automation, so let's just assume that
the other end is secure, okay?

    > All in all, it actually sounds to me like we may as well be not doing
    > anything here :) If admin's threat model allows for using the
    > self-generated self-signed cert, early expiration may be worse UX than
    > today - and if the threat model doesn't allow for that, the cert will
    > be replaced anyway.

+1
Changing from 10 years to 825 days is probably an acceptable move.
Maybe it should be a yocto-build-time configuration option.


[-- Attachment #1.2: Signature --]
[-- Type: text/plain, Size: 243 bytes --]

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Security Working Group meeting - this Wednesday February 19 - summary results

[Gunnar Mills]

On 2/19/2020 5:05 PM, Joseph Reynolds wrote:
> On 2/17/20 4:29 PM, Joseph Reynolds wrote:
>
>
>> 2. (Joseph, follow up to agenda item 3 from 2020-02-05): Redfish 
>> Privilege updates: 
>> https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/28881 and 
>> https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/28878 Update 
>> Feb 11: See 
>> https://redfishforum.com/thread/281/manageraccountcollection-change-allows-account-enumeration 
>> clarified the intention to NOT enumerate all accounts (unless you are 
>> the admin)

>
> Consensus was to leave OpenBMC as-is (only admin can enumerate users) 
> until Redfish releases a new spec.
>
This is implemented as Redfish intended, a user without ConfigureUsers 
privilege will only see their own account here: 
https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/28881

  We don't need to wait for the next Redfish release since Redfish is 
only further clarifying this in the documentation and implemented in 
28881 is how Redfish intended this to work. This fixes 2 validator 
errors if the validator is run as a ReadOnly or Operator role user.

Thx,
Gunnar