On 19/04/2016 01:51, Steve Marquess wrote:
> On 04/18/2016 04:05 PM, Leaky wrote:
>>>> plus you're constrained by the
>>>> requirements of the Security Policy to build the module with precisely
>>>> the commands:
>>>>
>>>> gunzip -c openssl-fips-2.0.12.tar.gz | tar xvf -
>>>> cd openssl-fips-2.0.12
>>>> ./config
>>>> make
>> Silly question... I know that you should only run the above commands, but
>> can you deviate from the unzip tool, i.e. use 7zip?
>>
>> I managed to get it to work without editing anything, but I am now wondering
>> if my process to compile the FIPS canister is bad purely because i am
>> storing the deflated tarball on our SVN and using that uncompressed code to
>> build from. Putting aside the fact that this is automated, and that it is
>> best to "run once and use many", should my script work with the raw tarball
>> straight from the web, and not a locally expanded copy?
> This is a mistake I've seen many times ("storing the deflated tarball on
> our SVN"). You're thinking like a software engineer, when you should be
> thinking like Alice down in the FIPS 140-2 rabbit hole.
>
> There is no point in attempting to do the usual configuration management
> and software version control on the contents of the
> openssl-fips-2.0.12.tar.gz tarball. You CANNOT change the content; there
> can be no changes to manage!!!
Almost true. If it wasn't banned by the FIPS security policy, checking in
the uncompressed tarball could be used to efficiently manage and track new
upstream releases of the tarball and to document which exact upstream FIPS
cannister source code (and hence corresponding validation date) was
incorporated into which product version (an aspect of FIPS compliance which
someone might want to audit
But alas, as you clarify below, this is not permitted by the OpenSSL FIPS
security policy directly incorporated into the validation.
The slightly less efficient idea of putting the compressed tarball into
the configuration control repository (which in this case *is* tracking the
build configuration, not the code versions) is probably (I am not sure)
againstthe policy that the tarball must be taken "securely" from the
physical CD mailed out by the OpenSSL foundation.
So the thing that can probably be put into a repository is the binary
FIPSCannister.o file along with copies of any documents certifying how,
where, from what and by whom said FIPS cannister was built.
Of cause, one could, purely for debugging/documentation purposes, include
a copy of the FIPS Cannister source code in the repository, one just
cannot compile anything releasable from it.
>
> The Security Policy is quite specific on the requirements, which make no
> allowance for the common sense (to a software engineer) fact that there
> are equivalent multiple ways to accomplish each step (such as unzipping
> the tarball). You are also specifically required to begin with the
> official tarball. Per the Security Policy, you *must* do:
>
> gunzip -c openssl-fips-2.0.12.tar.gz | tar xf -
>
> and *not* any functionally equivalent alternative such as:
>
> tar -zxf openssl-fips-2.0.12.tar.gz
>
> or even worse, a checkout of the expanded contents from your version
> management system.
>
> This is why I recommend you build the FIPS module once, manually,
> exactly per the documented requirements. It doesn't make sense, from the
> software engineering viewpoint, but is what the FIPS 140-2 validation
> bureaucracy insists on.
>
> -Steve M.
>
>
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
