Thank you for your well stated reply regarding FIPS compliance. I was trying to gather some basic feedback. I know there is a lot of moving parts to Koha. On a separate development project, I'm in the middle of FIPS compliance with some windows 11 PC's on a government level that have have decided to arbitrarily flip the FIPS switch to enabled in the group policys, and have virtually broken numerous applications overnight.
A side anomaly I have noticed, is an impact to http client modules that shouldn't have any impact to a FIPS enabled operating system, but that may or may not impact Koha development. I suspect if Koha does any kind of password hashing using any MD5 algorithms or baseEncoding logic, that it could impact that operation. Then there is 3rd party integrations like RabbitMQ that may be using encoding or serialization in line. But you are right - everything should be tested independently. There are FIPS compliance validation tools provided in Linux distros using oscap. sudo apt install openscap-scanner But that requires some setup with a oscap content file. If anyone is interested in this in the future, a sample content xml file might look something like this: > <XCCDF> > <Profile id="koha_profile"> > <title>Koha Security Profile</title> > <description>Security profile for Koha deployment</description> > <!-- Add security checks here --> > <select idref="koha_authentication_check"/> > <select idref="koha_access_control_check"/> > <!-- Add more checks as needed --> > </Profile> > <Group id="koha_group"> > <title>Koha Security Group</title> > <description>Group of security checks for Koha deployment</description> > <rule selected="true" idref="koha_profile"/> > </Group> > <Benchmark id="koha_benchmark"> > <title>Koha Security Benchmark</title> > <description>Benchmark for Koha deployment</description> > <profile idref="koha_profile"/> > </Benchmark> > <!-- Define specific security checks --> > <check id="koha_authentication_check" system="urn:scap:schema:xccdf:1.2"> > <description>Ensure strong authentication settings are > configured</description> > <!-- OVAL definition for authentication check --> > <check-export export-name="oval:org.koha.authentication_check"/> > </check> > <check id="koha_access_control_check" system="urn:scap:schema:xccdf:1.2"> > <description>Ensure proper access controls are in place</description> > <!-- OVAL definition for access control check --> > <check-export export-name="oval:org.koha.access_control_check"/> > </check> > <!-- Define OVAL definitions --> > <oval_definitions> > <definition id="org.koha.authentication_check" class="compliance"> > <!-- Define OVAL test for authentication --> > </definition> > <definition id="org.koha.access_control_check" class="compliance"> > <!-- Define OVAL test for access control --> > </definition> > <!-- Add more OVAL definitions as needed --> > </oval_definitions> > </XCCDF> then you can execute a scan with: > oscap xccdf eval --profile FIPS --results report.html scap-content-file.xml On Feb 21 2024, at 4:45 am, David Liddle <da...@liddles.net> wrote: > Hello Rudy, > > You might need to explain the context of your question in order to > receive a satisfactory answer. And I'm going to preface what I write > next with the statement that I am NOT a security professional, and you > should consult with system administrators who are experienced in FIPS > implementation before subjecting your library's data to advanced > cryptographic voodoo. Encryption is no trivial matter, and incorrect > implementation can render data eternally inaccessible. > > FIPS compliance refers most frequently to hardware modules that handle > cryptographic functions. There are also software modules that perform > these functions. Some of these are included in the Linux distributions > that can run Koha and will play a role in certain Koha processes. It > looks to me that FIPS compliance will center on the configuration of > the Linux kernel and OpenSSL, since they will do the bulk of the work > in ensuring that the main components of Koha do not employ > non-compliant cryptographic methods: > - operating system > - database server (MySQL or MariaDB) > - web server (Apache2) > - web languages (Perl, Python) > > I doubt that any Koha developer will tell you that the modules that > make up Koha were created with FIPS in mind. The security of your Koha > instances will be dependent in large part on the security of the > underlying system. Again, you should consult with system > administrators who have experience implementing FIPS. It would be wise > to thoroughly TEST a Koha instance on a system running in FIPS mode. > If you achieve success, I think that we'd all love to hear back from > you! > > Regards, > David Liddle > System Administrator > david.lid...@wycliff.de (but not for this list) > > Wycliff e.V., https://wycliff.de > Seminar für Sprache und Kultur, https://spracheundkultur.org > Internationales Tagungszentrum Karimu, https://karimu.de > > > On Tue, Feb 20, 2024 at 7:45 PM Rudy Hinojosa > <rudy.hinoj...@lightwavelibrary.com> wrote: > > > > Is Koha FIPS compliant? > > > > Rudy E. Hinojosa > > CEO/President, > > Lightwave Library > > > > Toll Free: 888-503-1727 (tel:TollFree:888-503-1727) lightwavelibrary.com > > (https://lightwavelibrary.com) > > > > rudy.hinoj...@lightwavelibrary.com > > (mailto:rudy.hinoj...@lightwavelibrary.com) > > > > P.O. Box 484, Liberty Hill, Texas 78642 > > (https://maps.google.com/?q=P.O.%20Box%20484,%20Liberty%20Hill,%20Texas%2078642) > > > > Life After Solutions LLC DBA: Lightwave Library > > > > _______________________________________________ > > > > Koha mailing list http://koha-community.org > > Koha@lists.katipo.co.nz > > Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha > _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
