Awesome investigation, explanation and ideas on how we can stay compliant once we reach that milestone. I have a few specific questions in-line:
On Thu, Nov 16, 2017 at 1:35 PM, Dmitri Dolguikh <witlessb...@gmail.com> wrote: > What is FIPS? > From Wikipedia [1]: The Federal Information Processing Standard (FIPS) > Publication 140-2, (FIPS PUB 140-2), is a U.S. government computer > security standard used to approve cryptographic modules. The title is > Security Requirements for Cryptographic Modules. > > What are Implications of FIPS 140-2 Support for Foreman, Katello, and > Smart-Proxy? > Linux system, or rather an SSL library in FIPS-compatible mode will > only have a set of ciphers and hash functions compatible with FIPS. > [2] contains the list of approved cryptographic functions, Oracle > graciously compiled the list of not approved ones, which is more > useful and can be found at [3]. > > > OpenSSL in FIPS mode > My understanding is that only OpenSSL versions 1.0.1 and 1.0.2 have > FIPS 140-2 validated cryptographic modules. OpenSSL raises ABRT signal > when it receives a call to one of the unapproved ciphers/functions. > > > Foreman in FIPS mode > I haven’t looked at pulp, candlepin, qpid, goferd, etc, and at point > don’t know how and if these can be made to work in FIPS mode. All > tests I’ve done so far were against Rails 5.0, Considering the number > of dependencies, we will need to limit FIPS support to just one > version of Rails. > Given we are targeting Rails 5.1 for the SCL we are building and it's the newest, does anything change here with using it? I have heard that the teams that work on those backend projects we use are/have looked into FIPS compliancy so we don't need to worry about that aspect. Sounds like we still need to look at the installer to ensure Kafo, Puppet and the Puppet modules are all FIPS compliant? > > Rails and other (ruby) dependencies. > MD5 is used (hard-coded) in a few places in Rails, at this point I’m > quite certain that its use is constrained to various built-in caches. > I had to disable *all* Rails caches to be able to run Foreman in FIPS > mode. Additionally, strong ETAG’s cannot be used, I’m not sure if they > are used, or there are plans for them. > Spring uses MD5 to generate application ID, but will use one in > SPRING_APPLICATION_ID environment variable if it’s available. > Gravatar uses MD5 hashes in their urls, doesn’t look like other hashes > are supported. > I think apipie cache uses MD5, but I will need to verify this. > > Foreman > app/services/password_crypt uses MD5 for grub2 passwords, which will > need to be switched to SHA512. MD5 will need to be removed from the > list of hash functions > SshKey#generate_fingerprint, call to SSHKey.fingerprint uses MD5 > > A note: with caching disabled, and issues above fixed, I was able to > get Foreman suite of tests to pass, and get Foreman to start. > > Smart-Proxy > Smart-Proxy codebase appears to be compatible with FIPS (ran and > passed tests ok without any changes), but there are issues with > external depdencies. > > DHCPD uses MD5-based omapi shared secret. DHCPD shared secret with > bind is also md5-based. > BIND when used with dhcpd uses MD5 hashes stored in TXT as host id. > Puppet needs to be run in FIPS mode (FIPS-compatible hash function > needs to be configured). I assume this covers all of puppet, including > mcollective, puppet run, puppetca. > BMC/IPMI authentication can use MD5 or lower based hashes, older > clients may not have newer hash functions. > Salt appears to use MD5 hashes by default, individual nodes must be > configured to use other hash_type > > Any 3rd party SSL certificates that may need to be verified or decoded > by either Foreman or Smart-Proxy must be generated using > FIPS-compatible algorithms/hash functions. > I suppose we could tests for this? For example, if a user provides custom SSL certificates for the web server we could run a check and warn a user? Is it possible to detect that a system is running in FIPS mode to only warn in that case? > > How we can reach FIPS compatibility > The easiest first step would be to replace offending cryptographic and > hash functions in Foreman, and in Smart-Proxy case, 3rd party > configuration files with FIPS-compatible ones. Additionally, any new > code changes that employ MD5 or other non approved functions shouldn’t > be accepted. > The next step would be to create a CI job that will continuously > execute the the full suite of tests on a VM with FIPS mode enabled. > GDB configured with Ruby’s project .gdbinit [4] and a tiny batch [5] > of commands can be used to report on FIPS-related failures. > How often do you see this CI job running? And I assume this would be temporary until we are fully FIPS compliant? > Considering the amount of dependencies Foreman and Smart-Proxy have, I > think would be useful to have all CI environments switched to run in > FIPS mode: this should increase the probability of discovering of new > FIPS-related issues before our users. > Lastly, a FIPS-compatible caching solution for Rails needs to be > found, if none exist, an existing one needs to be modified to support > FIPS. > Big +1 -- if we reach FIPS compliancy, then I am all for turning it on on all the Jenkins slaves as well as ensuring that our Vagrant boxes (for users and CI) have it turned out so we are running in that mode at all times. > > > Any feedback would be appreciated, > -d > > [1] Wikipedia article on FIPS 140-2, https://en.wikipedia.org/wiki/ > FIPS_140-2 > [2] Approved Security Functions for FIPS 140-2, > https://csrc.nist.gov/csrc/media/publications/fips/140/2/fin > al/documents/fips1402annexa.pdf > [3] List of algorithms not approved for FIPS 140-2, > https://docs.oracle.com/cd/E36784_01/html/E54953/fips-notok-1.html > [4] Ruby project’s gdb helper functions, > https://github.com/ruby/ruby/blob/trunk/.gdbinit > [5] Catching SIGABRTs with gdb and ruby-specific .gdbinit, > https://gist.github.com/witlessbird/904fefb0031c2eda96da61bd19424c86 > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Eric D. Helms Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
