Tomas Krizek wrote: > On 12/19/2016 04:41 PM, Standa Laznicka wrote: >> On 12/19/2016 03:07 PM, John Dennis wrote: >>> On 12/19/2016 03:12 AM, Standa Laznicka wrote: >>>> On 12/16/2016 03:23 PM, Rob Crittenden wrote: >>>>> Standa Laznicka wrote: >>>>>> Hello, >>>>>> >>>>>> I started a design page for FreeIPA on FIPS-enabled systems: >>>>>> https://www.freeipa.org/page/V4/FreeIPA-on-FIPS >>>>>> >>>>>> Me and Tomáš are still investigating what of all things will need to >>>>>> change in order to have FreeIPA on FIPS-enabled RHEL. So far I >>>>>> managed >>>>>> to install and run patched FreeIPA server and client and connect them >>>>>> together. >>>>>> >>>>>> There are some issues with NSS when trying to create an HTTPS request >>>>>> (apparently, NSS requires an NSS database password to set up an SSL >>>>>> connection). I am actually thinking of removing NSSConnection from >>>>>> the >>>>>> client altogether. >>>>> Can you expand on this a bit? NSS should only need a pin when it needs >>>>> access to a private key. What connection(s) are you talking about, and >>>>> what would you replace NSSConnection with? >>>>> >>>>> rob >>>> >>>> Hello Rob, >>>> >>>> Thank you for this excellent question, in order to cut the email >>>> short I >>>> seem to have omitted quite a few information. >>>> >>>> One of the very first problems I had with FreeIPA with FIPS was that >>>> NSS >>>> was always asking for password/pin. I was discussing this with the NSS >>>> guys on their IRC chat last week and it turns out that NSS tries to >>>> create a private key every time you want to use it as a backend for an >>>> SSL connection on FIPS. I still don't think this is quite right so I >>>> may >>>> open a bugzilla for that. >>> >>> I don't understand, I thought the case you were having problems with >>> was the FreeIPA client, not the server. I assume when you use the >>> term "backend" you mean server, and yes when NSS is in server mode it >>> will access to keys. So isn't the problem NSS is not being >>> initialized correctly so that it recognizes it is in client mode and >>> not server mode? >>> >> What I meant was "a client backend for an SSL connection" - we're >> using NSS implementation of SSL (via python-nss) for HTTPS connections >> from client to server during which we're getting a CA cert from an NSS >> database but this eventually leads to a password prompt. >>>> >>>> Anyway, the guys suggested me that we could try to create the database >>>> with an empty password and everything will work. I don't quite like >>>> that, too, but it's at least something if you don't want the `ipa` >>>> command to always bug you for password you have no way knowing if >>>> you're >>>> just a regular user. >>>> >>>> What I think would be a better way to go is to use >>>> httplib.HTTPSConnection. We have the needed certificates in >>>> /etc/ipa/ca.crt anyway so why not use them instead. We had a discussion >>>> with Honza this morning and it seems that with this approach we may get >>>> rid of the NSSConnection class altogether (although I still need to >>>> check a few spots) and start the process of moving away from NSS which >>>> was discussed some year ago in an internal mailing list (for some >>>> reason). >>>> >>>> Will be happy to hear thoughts on this, >>>> Standa >>> >>> I'm not a big fan of NSS, it has it's issues. As the author of the >>> Python binding I'm quite aware of all the nasty behaviors NSS has and >>> needs to be worked around. I wouldn't be sad to see it go but OpenSSL >>> has it's own issues too. If you remove NSS you're also removing the >>> option to support smart cards, HSM's etc. Perhaps before removing >>> functionality it would be good to assess what the requirements are. >>> >> I'm sorry I generalized too much, the original topic was moving away >> from python-nss (of which I am even more sorry as you're the author). >> > We could use some ideas on how to handle replica installations in FIPS. > > We might use some flag in LDAP to indicate that a topology is > FIPS-enabled. It seems like a good idea to force all servers in > FIPS-enabled topology to also be FIPS-enabled. At the start of replica > installation, a check could be performed to verify the FIPS topology > status is the same as the current system's FIPS status. However, this > proposal has a flaw. It is possible to simply install a FIPS-enabled > replica and then turn FIPS off. This would result in non-FIPS systems > being part of a FIPS-enabled topology. > > So we have a couple questions: > > Does it make sense to require all the servers in the topology to be > either FIPS-enabled or FIPS-disabled? > What would be a good approach to achieve this? Simply checking during > installation does not guarantee that FIPS will stay turned on. >
You could set some value in the replicated tree on FIPS status and write a 389-ds plugin to refuse to start if the environment doesn't match. Given this is started first it should cause a cascade of failures so no services are available. rob -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
