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

Wed Jan 25 15:39:13 UTC 2017

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20170125/66cd45c5/attachment.htm>