[Freeipa-devel] [DESIGN] FreeIPA on FIPS + NSS question

[Rob Crittenden]

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