On 01/13/2017 05:44 PM, Petr Vobornik wrote: > On 01/13/2017 03:49 PM, Rob Crittenden wrote: >> Tomas Krizek wrote: >>> On 01/12/2017 04:17 PM, Rob Crittenden wrote: >>>> 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 >>> Based on an offline discussion, we might just omit this feature >>> entirely. Our goal is to enable FreeIPA installation of FIPS configured >>> systems. It should be up to the customer to make sure other FIPS >>> requirements are met, i.e. all servers are configured to use FIPS. >>> >> Up to you but this is bound to be an RFE and seems like quite a weakness >> to me. >> >> You'll want to be sure to enforce that any additional masters get FIPS >> by default if the initial master has it. In other words, they shouldn't >> need to remember to pass an option, it should be automatic. >> >> rob >> > +1 to Rob. > > We could operate between the two extremes: > * Extreme 1: Ensuring that FIPS will remain enabled on all existing > replica. > * Extreme 2: Do not validate anything > > I.e. we could only: > * Note in LDAP that first server was installed with FIPS > * Check it at install time > - prevent from installation of non-FIPS > - prevent from installation of FIPS replica in non-FIPS topology > > It won't be bullet proof but it will check major mistakes which the > admin can do by accident. I've updated the design document [1], sections Multiple Servers in Topology (in Design and Implementation).
Instead of the originally proposed LDAP flag, we are proposing to check //proc/sys/crypto/fips_enabled /on the master (via RPC call) and on replica. Installation will proceed only if these match. See the design for more details. [1] - http://www.freeipa.org/page/V4/FreeIPA-on-FIPS -- Tomas Krizek
-- 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
