OpenBMC 2.8 security audit results

[Alexander Tereschenko]

On 22-Jun-20 16:08, Joseph Reynolds wrote:
> On 6/22/20 4:30 AM, Alexander Tereschenko wrote:
>> On 20-Jun-20 03:26, Joseph Reynolds wrote:
>>> Here are the results from my "security audit" on the planned OpenBMC 
>>> 2.8 release.  The results are not intended as a complete analysis, 
>>> but only offer highlights into the BMC's security configuration. 
>>> Contributions are appreciated.
>>> The script to perform these tests was presented here: 
>>> https://lists.ozlabs.org/pipermail/openbmc/2020-April/021186.html 
>>> and was followed more-or-less.
>>>
>>> $ echo "Checking test host openssl version"
>>> Checking test host openssl version
>>> $ openssl version
>>> OpenSSL 1.0.2k-fips  26 Jan 2017
>>>
>> I'm not sure I get this one - is "test host" a BMC or the one where 
>> the test script is being run? If the former, this is really old, no 
>> longer publicly supported by the OpenSSL team and has multiple CVEs 
>> against it [1], so should be upgraded.
>>
>> [1] https://www.openssl.org/news/openssl-1.0.2-notes.html
>
> Alexander, thanks for your reply.  The "test host" is a Linux system 
> used to probe the BMC via network interfaces such as SSH, HTTPS, and 
> REST APIs.  To reflect actual customer use, I used a test host that 
> has an older operating system.  I've included the test host's software 
> versions to help answer questions about the results below, when the 
> host version factors into the results. [I'll update my preamble with 
> this information.]

Got it, in this case that comment is not important, the text host may 
have whatever versions :)

>>> /etc/ssl/certs:
>>> drwx------    2 root     root           160 Jun 10 06:22 authority
>>> drwx------    2 root     root           304 Jun 10 06:23 https
>>>
>>> observation: Certificates under /etc/ssl are protected from reading
>>
>> This actually seems to be surplus - *certificates* are public by 
>> definition, it's the private parts of them (private keys 
>> corresponding to public ones in certificates) that need protection 
>> like that.
>
> Thanks for the clarification.  I've heard a private certificate is 
> improperly being stored along with its public cert in there somewhere, 
> but I don't really know.

Ah, indeed, that reminds me - OpenBMC stores both private key and the 
cert (with the public key) in one file, concatenated. That's how bmcweb 
consumes that (unlike e.g. Apache or nginx, which have separate 
settings/paths for private and public keys, though nginx also allows for 
combining) and indeed that in turn necessitates closing down the 
respective files/dirs - so your check is correct and my comment is not 
applicable.

regards,
Alexander