On 01/25/2017 12:46 PM, Tomas Krizek wrote: > 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 One more change from an offline discussion: we're going to use env.fips_mode variable instead of a dedicated RPC call.
-- 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
