Bug 590199

Btw, I also get some audit denied messages:

... avc:  denied  { getattr } for  pid=4287 comm="unix_chkpwd" path="/usr/sbin/prelink" ...

which sounds rather related.

Hmm. This may have something to do with the fact that the kernel I am running does not have FIPS enabled. Just before the crazy prelink execve, it did

   open("/proc/sys/crypto/fips_enabled", O_RDONLY) = -1 ENOENT (No such file or directory)

and when that failed, it started looking at "lib64/libfreebl3.chk".

There's another bugzilla (#524794) about kernels without FIPS enabled having problems. That one was reported last September, but maybe the bug re-appeared?

I just tested, and with the default Fedora kernel, things work fine. So it does seem to have something to do with kernel version or configuration. Which would explain why not everybody is screaming.

Confirmed. "su" starts working again if I enable CONFIG_CRYPTO_FIPS.

Anyway, please fix. Whatever tries to prelink libfreebl3 is some really horribly broken code, and something as fundamental as this shouldn't stop working (with no sane error messages) just because you don't have FIPS in the kernel.

Reverting back to nss-softokn{,-freebl} to 3.12.4-15 fixes the problem as well.

This was caused by the changes from bug #504949.

*** Bug 590269 has been marked as a duplicate of this bug. ***

Here's what's happening.

As mentioned in bug #524794, nss-softokn assumes FIPS is enabled when /proc/sys/crypto/fips_enabled doesn't exists, which happens when a kernel is built with CONFIG_CRYPTO_FIPS=n.

The fix is very simple:
     f = fopen("/proc/sys/crypto/fips_enabled", "r");
     if (!f)
-        return 1;
+        return 0;

I tested this, and now I can login.

Here's a koji build with the patch:
https://koji.fedoraproject.org/koji/taskinfo?taskID=2174243

However, in theory the same problems will happen when /proc/sys/crypto/fips_enabled is 1.

The problems can be explained by bug #504949 comment #43:
> I've changed prelink recently (starting with 0.4.3) to allow
> prelink -u -o - /lib/libfreebl3.so
> to output undo on stdout where the library when in fips strict mode can
> checksum it.

Therefore nss-softokn-3.12.4-17 should depend on prelink-0.4.3 which is not the case on F12, and the patch in nss-softokn-3.12.4-17 doesn't check for the prelink version.

Can the fixed package please be pushed out asap? The current package is
clearly totally buggy, fedora-12 is not supposed to be some "rawhide" thing
that works or not based on random phases of the moon.

And why wasn't the "very simple" fix applied back in September of last year
when that bug was reported? Or was it applied and then lost again?

From what I can understand there are two problems:
1) CONFIG_CRYPTO_FIPS=n enables FIPS (has always been there)
2) enabling FIPS breaks the system with nss-softokn-3.12.4-17

F12 should work properly whether FIPS is enabled or not.

The problem reported on bug #524794 was *not* that CONFIG_CRYPTO_FIPS=n broke the system(1); it was the enabling FIPS broke the system. It seems that bug was solved when F12 was released, but things broke again with nss-softokn-3.12.4-17. So those are two separate bugs.

Apparently everyone forgot about bug #1.

We, the people that run a kernel with CONFIG_CRYPTO_FIPS=n, apparently are the only ones that noticed this problem (2). I couldn't care less about FIPS; I just want to be able to login to my system, pushing forward my proposed fix would achieve that.

On Sat, 8 May 2010, Felipe Contreras  wrote:
> 
> The problem reported on bug #524794 was *not* that CONFIG_CRYPTO_FIPS=n broke
> the system(1); it was the enabling FIPS broke the system.

Incorrect.

524794 very clearly states that the bug was that 

        1. Build a kernel without CONFIG_CRYPTO_FIPS.
        2. Install it, reboot.
        3. Try to login with the correct password.

and that it was broken.

Now, 524794 then _also_ started talking about how enabling fips was broken 
even when fips was supported by the kernel, but the initial bug-report was 
all about CONFIG_CRYPTO_FIPS=n being broken.

And it clearly is _still_ broken, almost six months later. Whether it was 
ever fixed in the meantime is possible, of course.

(In reply to comment #9)
> On Sat, 8 May 2010, Felipe Contreras  wrote:
> > 
> > The problem reported on bug #524794 was *not* that CONFIG_CRYPTO_FIPS=n broke
> > the system(1); it was the enabling FIPS broke the system.
> 
> Incorrect.
> 
> 524794 very clearly states that the bug was that 
> 
>         1. Build a kernel without CONFIG_CRYPTO_FIPS.
>         2. Install it, reboot.
>         3. Try to login with the correct password.
> 
> and that it was broken.

Those were the steps to reproduce.

The bug was:
Wrong check for fips_enabled breaks login on kernels with CONFIG_CRYPTO_FIPS=n

Strictly speaking, that was fixed, since the wrong check for fips_enabled didn't break logins any more.

> Now, 524794 then _also_ started talking about how enabling fips was broken 
> even when fips was supported by the kernel, but the initial bug-report was 
> all about CONFIG_CRYPTO_FIPS=n being broken.

Since comment #1 the bug was used for fips=1 problems.

Clearly, on bug #524794 comment #3, Bob hijacked the efforts:
> This means we need to fix this fips=1 bug, which would make the main issue
> described here less of one.

Anyway, that's history, I hope we agree on two things:
1) CONFIG_CRYPTO_FIPS=n should not turn on FIPS
2) Whether or not FIPS works is irrelevant for this bug

Which bug is used to achieve 1), I don't care much, but in the package I created, I referenced this one.

I realized I made a tyo in the spec file. See
https://bugzilla.redhat.com/show_bug.cgi?id=504949#c60

> Those were the steps to reproduce.
>
> The bug was:
> Wrong check for fips_enabled breaks login on kernels with CONFIG_CRYPTO_FIPS=n

Having some serious reading problems, are you?

The text you quoted is EXACTLY about that CONFIG_CRYPTO_FIPS=n case.
And that is *the* case that is BROKEN right now.

So why do you claim that "it was fixed"? It clearly was not fixed. It's
the exact bug I hit yesterday.

What's your problem? You even quote that "CONFIG_CRYPTO_FIPS=n" being
clearly there, and then you go on to say over and over that it's about
"fips=1" even though IT CLEARLY WAS NOT.

Stop making excuses. Stop trying to make it about "fips=1", when it was
not at all about that. It was later _expanded_ to talk about that too,
but no, that clearly was _not_ the main bug report. And by clearly, I
say that both the main subject _and_ the first comment make it very very
clear that "CONFIG_CRYPTO_FIPS=n" was broken.

And it's still broken almost six months later. It's the thing my bug-report
also talks about. So please just make sure it gets fixed, and the fixed thing
gets pushed out. And don't try to make this about "fips=1", because it wasn't.
Not in the original bug report, and not in my bug report.

A scratch build is at
http://koji.fedoraproject.org/koji/tasks?owner=emaldonado&state=closed&view=tree&method=all&order=-completion_time
My test:
[root@fedora12devel Downloads]# rpm -qa | grep ^nss-softokn
nss-softokn-3.12.4-10.fc12.x86_64
nss-softokn-freebl-3.12.4-17.fc12.x86_64
[root@fedora12devel Downloads]# rpm -qa | grep ^prelink
prelink-0.4.2-4.fc12.x86_64
When I try to update softokn:
Loaded plugins: auto-update-debuginfo, presto, refresh-packagekit
Setting up Local Package Process
Examining nss-softokn-3.12.4-18.fc12.x86_64.rpm: nss-softokn-3.12.4-18.fc12.x86_64
Marking nss-softokn-3.12.4-18.fc12.x86_64.rpm as an update to nss-softokn-3.12.4-10.fc12.x86_64
Found 35 installed debuginfo package(s)
Examining nss-softokn-freebl-3.12.4-18.fc12.x86_64.rpm: nss-softokn-freebl-3.12.4-18.fc12.x86_64
Marking nss-softokn-freebl-3.12.4-18.fc12.x86_64.rpm as an update to nss-softokn-freebl-3.12.4-17.fc12.x86_64
Resolving Dependencies
--> Running transaction check
---> Package nss-softokn.x86_64 0:3.12.4-18.fc12 set to be updated
---> Package nss-softokn-freebl.x86_64 0:3.12.4-18.fc12 set to be updated
--> Processing Conflict: nss-softokn-freebl-3.12.4-18.fc12.x86_64 conflicts prelink < 0.4.3
--> Finished Dependency Resolution
Error: nss-softokn-freebl conflicts with prelink
 ---- two more lines skipped ---
Which is what we want, nss-softokn won't be updated until prelink reaches 0.4.3.

Why do you keep on harping on that "prelink" problem?

The first problem is that the whole prelink thing shouldn't have been done
AT ALL. 

The fact that "fips=1" was then _also_ broken is a totally separate bug.
I really don't care. I don't have FIPS enabled at all, I'm certainly not
going to care about "fips=1".

In other words - if "prelink" ends up being run just because I don't even
have FIPS enabled, it's a bug. It's a bug whether prelink is then fixed
or not. 

Please don't use this bugzilla entry to update prelink dependencies for the
package. I don't care. It's not why I opened the bug entry. Please make
sure that if the kernel doesn't have FIPS support, then nss-softokn-freebl
doesn't even _bother_ to do the check and the prelink reset. 

If you do that, and push out the fixed package, you can close the bugzilla
entry. I don't care one whit whether "fips=1" then works or not.

Ok?

(In reply to comment #12)
> > Those were the steps to reproduce.
> >
> > The bug was:
> > Wrong check for fips_enabled breaks login on kernels with CONFIG_CRYPTO_FIPS=n
> 
> Having some serious reading problems, are you?
> 
> The text you quoted is EXACTLY about that CONFIG_CRYPTO_FIPS=n case.
> And that is *the* case that is BROKEN right now.

No, it's about not being able to LOGIN _and_ CONFIG_CRYPTO_FIPS=n. The reporter himself identified the issue in bug #524794 #comment 3.

When nss-softokn-3.12.4-10 was released, the bug could be considered fixed because it met the expected results:

    Authentication should succeed.

If the bug had expected results:

    FIPS should be disabled when CONFIG_CRYPTO_FIPS=n

Then it would be clear that the bug wasn't fixed, but since that's not the case, it's not clear-cut.

But I don't care about that. The fact of the matter is that everyone forgot about the CONFIG_CRYPTO_FIPS=n part... that's all I was trying to explain.

> So why do you claim that "it was fixed"? It clearly was not fixed. It's
> the exact bug I hit yesterday.

There are 3 bugs. One of the bugs reported in bug #524794 was fixed, the other one is not. What you hit is a combination of two bugs, one that was introduced with nss-softokn-3.12.4-17.

> What's your problem? You even quote that "CONFIG_CRYPTO_FIPS=n" being
> clearly there, and then you go on to say over and over that it's about
> "fips=1" even though IT CLEARLY WAS NOT.

I'm saying that's how everyone threated it.

> Stop making excuses. Stop trying to make it about "fips=1", when it was
> not at all about that. It was later _expanded_ to talk about that too,
> but no, that clearly was _not_ the main bug report. And by clearly, I
> say that both the main subject _and_ the first comment make it very very
> clear that "CONFIG_CRYPTO_FIPS=n" was broken.
> 
> And it's still broken almost six months later. It's the thing my bug-report
> also talks about. So please just make sure it gets fixed, and the fixed thing
> gets pushed out. And don't try to make this about "fips=1", because it wasn't.
> Not in the original bug report, and not in my bug report.    

I'm not making excuses, I'm trying to explain what happened based on what I can see. Also, I have nothing to do with FIPS, or NSS, I'm just another user like you bitten by this bug. I read the two bugs, I think I understood the situation, and fixed it for me.

I have no interest in debating whether bug #524794 was really fixed, or partially fixed, or not fixed at all; I don't think it serves any purpose.

The only productive thing left to do IMO is to push the package with the fix, for which I've done all I could, now it's up to Fedora maintainers.

(In reply to comment #14)
> Please don't use this bugzilla entry to update prelink dependencies for the
> package. I don't care. It's not why I opened the bug entry. Please make
> sure that if the kernel doesn't have FIPS support, then nss-softokn-freebl
> doesn't even _bother_ to do the check and the prelink reset. 
> 
> If you do that, and push out the fixed package, you can close the bugzilla
> entry. I don't care one whit whether "fips=1" then works or not.
> 
> Ok?    

Elio is tackling this bug the way you reported it:
---
"su" and screensaver stopped working - not accepting passwords

expected results:
I expect to be root and install kernels or do yum upgrades to fix user
level bugs.
---

*Strictly* speaking, Elio would be fixing this bug if nss-softokn 3.12.4-18 depends on prelink >= 0.4.3, even if CONFIG_CRYPTO_FIPS=n turns FIPS on.

Which is clearly not what we want, so please change the summary of this bug to avoid confusion/hijacking.

@Elio how about picking my patch as well?
> Here's a koji build with the patch:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=2174243

Obviously CONFIG_CRYPTO_FIPS=n in the kernel should not turn FIPS on.

(In reply to comment #17) It looks good to me, could you attach the patch to this bug?

Created attachment 412590 [details]
Fix for FIPS disabled in kernel

Proposed patch... should have been applied long time ago.

Comment on attachment 412590 [details]
Fix for FIPS disabled in kernel

This patch lies inside the fips boundary.

Comment on attachment 412590 [details]
Fix for FIPS disabled in kernel

The problem is that this patch makes  mssslow_GetFIPSEnabled return 1 (true the OS is FIPS enabled) when the file isn't there. That reverses the semantics of the call. The fix lies elsewhere.

(In reply to comment #21) Oops, the only thing reversed are my eyes :-)
-        return 1;
+        return 0;
is indeed what we want to change.

nss-softokn-3.12.4-18.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/nss-softokn-3.12.4-18.fc12

nss-softokn-3.12.4-18.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/nss-softokn-3.12.4-18.fc13

(In reply to comment #19) attachment (id=412590) included in the Rawhide build http://koji.fedoraproject.org/koji/buildinfo?buildID=172563

(In reply to comment #23)
> nss-softokn-3.12.4-18.fc12 has been submitted as an update for Fedora 12.
> http://admin.fedoraproject.org/updates/nss-softokn-3.12.4-18.fc12    

No, no, no, no!

Linus clearly stated that this bug is not about fixing fips=1. What part of comment #14 wasn't clear?

The summary should be:

     FIPS wrongly enabled when CONFIG_CRYPTO_FIPS=n

Clearly, nss-softokn-3.12.4-18.fc12 doesn't fix that. Linus, again, please update the summary to avoid confusion; the bug is already on MODIFIED state on the way to be marked as fixed.

Also this update is pretty useless at the moment as it seems to require prelink >= 0.4.3 which doesn't seem to be available (in updates-testing at least).

(In reply to comment #27)
> Also this update is pretty useless at the moment as it seems to require prelink
> >= 0.4.3 which doesn't seem to be available (in updates-testing at least).    

Yes, it should be the other way around:
 1) Fix CONFIG_CRYPTO_FIPS=n
 2) Then do whatever you want (without breaking fips=0) (irrelevant to this bug)

I fear Red Hat people are hijacking this bug for FIPS testbed.

nss-softokn-3.12.4-19.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/nss-softokn-3.12.4-19.fc12

Mind you, this is for updates testing ONLY. Think of it as a more convenient form of a scratch build that, to think about it, should have been the vehicle. I will NOT push this to stable until there is additional review, not just testing.

nss-softokn-3.12.4-19.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update nss-softokn'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/nss-softokn-3.12.4-19.fc12

This update doesn't appear to be sufficient; login still fails, and I get selinux errors about "/sbin/unix_chkpwd "getattr" access on /usr/sbin/prelink.".

I can't update nss-softtokn-freebl because of its dependency on prelink, which doesn't appear to be available in updates-testing.

Comment on attachment 412590 [details]
Fix for FIPS disabled in kernel

r+ rrelyea.

This is what I should have been implemented in the first place.

(In reply to comment #32)
> I can't update nss-softtokn-freebl because of its dependency on prelink, which
> doesn't appear to be available in updates-testing.
You will able to do it soon, prelink 0.4.3 was submitted today to upstate-testing http://koji.fedoraproject.org/koji/buildinfo?buildID=166845

(In reply to comment #30)
> Mind you, this is for updates testing ONLY. Think of it as a more convenient
> form of a scratch build that, to think about it, should have been the vehicle.
> I will NOT push this to stable until there is additional review, not just
> testing.

Why? Why are we following RedHat guidelines for a *Fedora* bug. The patch is obviously OK, anyone with half a brain would agree.

*** Bug 592432 has been marked as a duplicate of this bug. ***

nss-softokn-3.12.4-19.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

This is fixed in F12, but broken in F13 - which doesn't have nss-softokn updated packages.

Please forward port the changes for F13.

nss-softokn-3.12.4-19.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/nss-softokn-3.12.4-19.fc13

nss-softokn-3.12.4-19.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

After last round of yum update, the nss-softokn-3.12.4-19.fc13 package for F13 is included and confirmed working as expected. Thanks.

Sorry - it's not over yet :(

It appears that both the nss-softokn and the nss-softokn-freebl RPM packages aren't available in the 32-bit version (i686) for x86_64 F13 (notice how the -devel updated packages are present for both i686 and x86_64).

This prevents (in my case) wine from being installed via yum, as
 -> wine.x86_64 requires wine.i686
 -> wine.i686 requires nss-softokn-freebl.i686
 -> nss-softokn-freebl.i686 isn't available as update, and yum complains that the base i686 package is older than its updated x86_64 counterpart

Please also provide i686 updated versions of nss-softokn and nss-softokn-freebl.. Thanks!

(In reply to comment #42) Alenssandro, please log this as a new bug. I don't think this update is the culprit but rather nss's requirement on softokn to be of the same arch. Thanks.

(In reply to comment #43) Never mind, let's use Bug 596840.

*** Bug 590247 has been marked as a duplicate of this bug. ***

Thanks Elio, I noted bug 596840 as current for my latest issue and will follow that one instead of this.