Re: nfsd needs "md5", but fips=1 disables it -> hang

Re: nfsd needs "md5", but fips=1 disables it -> hang

[J. Bruce Fields]

On Thu, Mar 27, 2014 at 08:52:39PM +1100, NeilBrown wrote:
> 
> [I sent this 2 days ago but haven't seen it come back on the nfs
>  list and don't see it in the archives.  Maybe someone we cannot name
>  filtered it because it contains the word 'crypto' ??]

Huh.

> Apparently there is a thing called "FIPS" which lists some approved crypto
> algorithms.  And some sites need to only use those.  So they boot their
> kernel with
>     fips=1
> and anything non-fips-approved stops working.
> 
> "md5" is not fips-approved.
> 
> So
> 
> 	desc.tfm = crypto_alloc_hash("md5", 0, CRYPTO_ALG_ASYNC);
> 
> in
> 
> nfs4_make_rec_clidname(char *dname, const struct xdr_netobj *clname)
> 
> 
> always fails when fips=1.  This interferes with efficient NFS service (every
> 'open' hangs).
> 
> s/md5/sha1/
> 
> makes this problem go away, because sha1 is fips-approved.
> 
> My question is: is this safe, or is the hash value used in some external way
> (in /var/lib/nfs/v4recovery ??).

Right, it's used in v4recovery, so you'd lose client state when you
rebooted the server to the new (SHA1-using) server.

Our intention was to migrate people that care about FIPS to the umh
upcall.  But rhel6 has a hack (a private md5 implementation).

Cc'ing jlayton (currently traveling) who did that work.

--b.

> 
> If changing the hash to sha1 is safe, we should do that and probably add
>   select CRYPTO_SHA1
> to Kconfig just to be safe.
> 
> If we really need to keep it stable, I guess we need to find a way to perform
> md5 computations that bypasses the fips checks.

Re: nfsd needs "md5", but fips=1 disables it -> hang

[Jeff Layton]

On Thu, 27 Mar 2014 10:30:24 -0400
"J. Bruce Fields" <bfields@fieldses.org> wrote:

> On Thu, Mar 27, 2014 at 08:52:39PM +1100, NeilBrown wrote:
> > 
> > [I sent this 2 days ago but haven't seen it come back on the nfs
> >  list and don't see it in the archives.  Maybe someone we cannot
> > name filtered it because it contains the word 'crypto' ??]
> 
> Huh.
> 
> > Apparently there is a thing called "FIPS" which lists some approved
> > crypto algorithms.  And some sites need to only use those.  So they
> > boot their kernel with
> >     fips=1
> > and anything non-fips-approved stops working.
> > 

Yes. As best I can tell, the primary purpose of FIPS is to render the
machine unusable for any non-trivial purpose. ;)

The story I have heard is that FIPS carves out an exemption for the use
of unapproved crypto as long as it stays "within the
implementation" (whatever that means).

> > "md5" is not fips-approved.
> > 
> > So
> > 
> > 	desc.tfm = crypto_alloc_hash("md5", 0, CRYPTO_ALG_ASYNC);
> > 
> > in
> > 
> > nfs4_make_rec_clidname(char *dname, const struct xdr_netobj *clname)
> > 
> > 
> > always fails when fips=1.  This interferes with efficient NFS
> > service (every 'open' hangs).
> > 
> > s/md5/sha1/
> > 
> > makes this problem go away, because sha1 is fips-approved.
> > 
> > My question is: is this safe, or is the hash value used in some
> > external way (in /var/lib/nfs/v4recovery ??).
> 

The hashes aren't used outside the machine and they're not even
cryptographically significant. The kernel only uses it as a way to
squash the long-form clientid into something that it can use as a
directory name.

In hindsight, the decision to use md5 for that purpose was
unfortunate...

> Right, it's used in v4recovery, so you'd lose client state when you
> rebooted the server to the new (SHA1-using) server.
> 
> Our intention was to migrate people that care about FIPS to the umh
> upcall.  But rhel6 has a hack (a private md5 implementation).
> 
> Cc'ing jlayton (currently traveling) who did that work.
> 

Yep, exactly.

For any newer kernels and nfs-utils, just use nfsdcltrack and don't
bother with the legacy code. Eventually I can forsee us getting rid of
the legacy client tracking.

> > 
> > If changing the hash to sha1 is safe, we should do that and
> > probably add select CRYPTO_SHA1
> > to Kconfig just to be safe.
> > 
> > If we really need to keep it stable, I guess we need to find a way
> > to perform md5 computations that bypasses the fips checks.

For RHEL6 I just made a private md5 implementation. I had considered
switching it to sha1 instead, but the problem is that you'll lose
persistent state if you upgrade the kernel and it switches the hashing
implementation.

-- 
Jeff Layton <jlayton@redhat.com>

Re: nfsd needs "md5", but fips=1 disables it -> hang

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 3713 bytes --]

On Thu, 27 Mar 2014 13:11:32 -0700 Jeff Layton <jlayton@redhat.com> wrote:

> On Thu, 27 Mar 2014 10:30:24 -0400
> "J. Bruce Fields" <bfields@fieldses.org> wrote:
> 
> > On Thu, Mar 27, 2014 at 08:52:39PM +1100, NeilBrown wrote:
> > > 
> > > [I sent this 2 days ago but haven't seen it come back on the nfs
> > >  list and don't see it in the archives.  Maybe someone we cannot
> > > name filtered it because it contains the word 'crypto' ??]
> > 
> > Huh.

And my email still didn't get to the list, but at least it got to Bruce.
And you replies only got to be directly, not through the list!
Very weird ... I wonder if I care....

> > 
> > > Apparently there is a thing called "FIPS" which lists some approved
> > > crypto algorithms.  And some sites need to only use those.  So they
> > > boot their kernel with
> > >     fips=1
> > > and anything non-fips-approved stops working.
> > > 
> 
> Yes. As best I can tell, the primary purpose of FIPS is to render the
> machine unusable for any non-trivial purpose. ;)

I'd notice this wasn't the only thing that broke.  However it appear to be a
thing that we want to support :-(

> 
> The story I have heard is that FIPS carves out an exemption for the use
> of unapproved crypto as long as it stays "within the
> implementation" (whatever that means).

So it is probably ok to use md5 as long as we don't pretend that we are doing
crypto (which we aren't)

> 
> > > "md5" is not fips-approved.
> > > 
> > > So
> > > 
> > > 	desc.tfm = crypto_alloc_hash("md5", 0, CRYPTO_ALG_ASYNC);
> > > 
> > > in
> > > 
> > > nfs4_make_rec_clidname(char *dname, const struct xdr_netobj *clname)
> > > 
> > > 
> > > always fails when fips=1.  This interferes with efficient NFS
> > > service (every 'open' hangs).
> > > 
> > > s/md5/sha1/
> > > 
> > > makes this problem go away, because sha1 is fips-approved.
> > > 
> > > My question is: is this safe, or is the hash value used in some
> > > external way (in /var/lib/nfs/v4recovery ??).
> > 
> 
> The hashes aren't used outside the machine and they're not even
> cryptographically significant. The kernel only uses it as a way to
> squash the long-form clientid into something that it can use as a
> directory name.
> 
> In hindsight, the decision to use md5 for that purpose was
> unfortunate...

Isn't there a book about that .. "A series of unfortunate decisions" ...


> 
> > Right, it's used in v4recovery, so you'd lose client state when you
> > rebooted the server to the new (SHA1-using) server.
> > 
> > Our intention was to migrate people that care about FIPS to the umh
> > upcall.  But rhel6 has a hack (a private md5 implementation).
> > 
> > Cc'ing jlayton (currently traveling) who did that work.
> > 
> 
> Yep, exactly.
> 
> For any newer kernels and nfs-utils, just use nfsdcltrack and don't
> bother with the legacy code. Eventually I can forsee us getting rid of
> the legacy client tracking.

Where "newer" means .... Linux v3.8 and nfs-utils 1.2.7.
I'll keep that in mind for future releases then, thanks.


> 
> > > 
> > > If changing the hash to sha1 is safe, we should do that and
> > > probably add select CRYPTO_SHA1
> > > to Kconfig just to be safe.
> > > 
> > > If we really need to keep it stable, I guess we need to find a way
> > > to perform md5 computations that bypasses the fips checks.
> 
> For RHEL6 I just made a private md5 implementation. I had considered
> switching it to sha1 instead, but the problem is that you'll lose
> persistent state if you upgrade the kernel and it switches the hashing
> implementation.
> 

Sounds like a plan ... thanks for the help.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: nfsd needs "md5", but fips=1 disables it -> hang

[Jeff Layton]

[-- Attachment #1: Type: text/plain, Size: 4512 bytes --]

On Mon, 31 Mar 2014 17:54:58 +1100
NeilBrown <neilb@suse.de> wrote:

> On Thu, 27 Mar 2014 13:11:32 -0700 Jeff Layton <jlayton@redhat.com> wrote:
> 
> > On Thu, 27 Mar 2014 10:30:24 -0400
> > "J. Bruce Fields" <bfields@fieldses.org> wrote:
> > 
> > > On Thu, Mar 27, 2014 at 08:52:39PM +1100, NeilBrown wrote:
> > > > 
> > > > [I sent this 2 days ago but haven't seen it come back on the nfs
> > > >  list and don't see it in the archives.  Maybe someone we cannot
> > > > name filtered it because it contains the word 'crypto' ??]
> > > 
> > > Huh.
> 
> And my email still didn't get to the list, but at least it got to Bruce.
> And you replies only got to be directly, not through the list!
> Very weird ... I wonder if I care....
> 

That is odd. Might be worth talking to DaveM and company and seeing why
they're getting dropped...

> > > 
> > > > Apparently there is a thing called "FIPS" which lists some approved
> > > > crypto algorithms.  And some sites need to only use those.  So they
> > > > boot their kernel with
> > > >     fips=1
> > > > and anything non-fips-approved stops working.
> > > > 
> > 
> > Yes. As best I can tell, the primary purpose of FIPS is to render the
> > machine unusable for any non-trivial purpose. ;)
> 
> I'd notice this wasn't the only thing that broke.  However it appear to be a
> thing that we want to support :-(
> 
> > 
> > The story I have heard is that FIPS carves out an exemption for the use
> > of unapproved crypto as long as it stays "within the
> > implementation" (whatever that means).
> 
> So it is probably ok to use md5 as long as we don't pretend that we are doing
> crypto (which we aren't)
> 

Probably, yes... The other problem with FIPS is that it's apparently
filled with a lot of weasel-words so getting definitive answers for
this sort of thing is pretty tough.

> > 
> > > > "md5" is not fips-approved.
> > > > 
> > > > So
> > > > 
> > > > 	desc.tfm = crypto_alloc_hash("md5", 0, CRYPTO_ALG_ASYNC);
> > > > 
> > > > in
> > > > 
> > > > nfs4_make_rec_clidname(char *dname, const struct xdr_netobj *clname)
> > > > 
> > > > 
> > > > always fails when fips=1.  This interferes with efficient NFS
> > > > service (every 'open' hangs).
> > > > 
> > > > s/md5/sha1/
> > > > 
> > > > makes this problem go away, because sha1 is fips-approved.
> > > > 
> > > > My question is: is this safe, or is the hash value used in some
> > > > external way (in /var/lib/nfs/v4recovery ??).
> > > 
> > 
> > The hashes aren't used outside the machine and they're not even
> > cryptographically significant. The kernel only uses it as a way to
> > squash the long-form clientid into something that it can use as a
> > directory name.
> > 
> > In hindsight, the decision to use md5 for that purpose was
> > unfortunate...
> 
> Isn't there a book about that .. "A series of unfortunate decisions" ...
> 
> 
> > 
> > > Right, it's used in v4recovery, so you'd lose client state when you
> > > rebooted the server to the new (SHA1-using) server.
> > > 
> > > Our intention was to migrate people that care about FIPS to the umh
> > > upcall.  But rhel6 has a hack (a private md5 implementation).
> > > 
> > > Cc'ing jlayton (currently traveling) who did that work.
> > > 
> > 
> > Yep, exactly.
> > 
> > For any newer kernels and nfs-utils, just use nfsdcltrack and don't
> > bother with the legacy code. Eventually I can forsee us getting rid of
> > the legacy client tracking.
> 
> Where "newer" means .... Linux v3.8 and nfs-utils 1.2.7.
> I'll keep that in mind for future releases then, thanks.
> 
> 
> > 
> > > > 
> > > > If changing the hash to sha1 is safe, we should do that and
> > > > probably add select CRYPTO_SHA1
> > > > to Kconfig just to be safe.
> > > > 
> > > > If we really need to keep it stable, I guess we need to find a way
> > > > to perform md5 computations that bypasses the fips checks.
> > 
> > For RHEL6 I just made a private md5 implementation. I had considered
> > switching it to sha1 instead, but the problem is that you'll lose
> > persistent state if you upgrade the kernel and it switches the hashing
> > implementation.
> > 
> 
> Sounds like a plan ... thanks for the help.
> 

No problem. What I basically did was copy crypto/md5.c to the nfsd
directory and scrape out all of the crypto API goop. md5_transform() is
still available even when fips=1 is enabled. ;)

-- 
Jeff Layton <jlayton@redhat.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]