Bug 878212

Created attachment 648124 [details]
avcs

AFAIK prelink is forbidden on FIPS machines.

Go to following URL and search for "prelink":
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-Federal_Standards_And_Regulations-Federal_Information_Processing_Standard.html

(In reply to comment #3)
> AFAIK prelink is forbidden on FIPS machines.

Correct, but next time please read the problem description more closely before closing a bug report, to quote from it:

"
Note that /sbin/unix_chkpwd is not prelinked, prelink -u -v says:

[hans@localhost ~]$ sudo prelink -u -v /sbin/unix_chkpwd 
prelink: /sbin/unix_chkpwd does not have .gnu.prelink_undo section

And I've PRELINKING=no in /etc/sysconfig/prelink and ran a "prelink -u -a" before enabling fips mode, as per: https://access.redhat.com/knowledge/solutions/137833
"

So prelinking *is* disabled yet this is still happening, which is why I also wrote:

"It seems as for some reason pam is trying to run prelink on /sbin/unix_chkpwd, likely pam_unix.so wants to verify its hash, and runs it through prelink to sure the verification will succeed even if the binary is prelinked."

Note that neither pam_unix nor unix_chkpwd does any prelinking. This is most probably from the nss as glibc calls into nss soft token for sha256 and sha512. Are the shared library files in nss-softtokn package prelinked?

(In reply to comment #6)
> Note that neither pam_unix nor unix_chkpwd does any prelinking. This is most
> probably from the nss as glibc calls into nss soft token for sha256 and
> sha512. Are the shared library files in nss-softtokn package prelinked?

As l've already written *twice* now I've exactly followed the instructions from:
https://access.redhat.com/knowledge/solutions/137833

And set PRELINKING=no in /etc/sysconfig/prelink and then ran "prelink -u -a"

Thus unsurprisingly:

[hans@localhost ~]$ for i in $(rpm -ql nss-softokn | grep 3.so); do sudo prelink -u -v $i; done
prelink: /usr/lib64/libnssdbm3.so does not have .gnu.prelink_undo section
prelink: /usr/lib64/libsoftokn3.so does not have .gnu.prelink_undo section
prelink: /usr/lib/libnssdbm3.so does not have .gnu.prelink_undo section
prelink: /usr/lib/libsoftokn3.so does not have .gnu.prelink_undo section

Have you tried reproducing this yourself? Simply update a 6.4 install / vm to the latest nightly and the follow:
https://access.redhat.com/knowledge/solutions/137833

Note, If you then can no longer log in, put selinux in permissive mode to get your system back.

Workaround is to uninstall the prelink package.

I think this is problem of the nss soft token that it unconditionally tries to undo the prelinking on itself before computing the checksum. However as nss softtoken probably cannot be changed (it is already FIPS validated) this will have to be allowed in the SELinux policy. But there is problem that basically anything that calls crypt() from glibc will have to be able to execute prelink.

So we would need to add 

tunable_policy(`fips_mode',`
prelink_exec(domain)
..
..
')

(In reply to comment #8)
> Workaround is to uninstall the prelink package.
> 
> I think this is problem of the nss soft token that it unconditionally tries
> to undo the prelinking on itself before computing the checksum. However as
> nss softtoken probably cannot be changed (it is already FIPS validated) this
> will have to be allowed in the SELinux policy. But there is problem that
> basically anything that calls crypt() from glibc will have to be able to
> execute prelink.

There are already special instructions for using fips, ie:
https://access.redhat.com/knowledge/solutions/137833

(note there are more places with similar instructions, ie the installation guide iirc)

So we could also fix this by updating the docs, and telling users to uninstall prelink after first disabling it and un-prelinking everything.

Also note the Fedora-18 does not seem to have this problem, so it would be good to try and figure out why this is not happening there.

The problem is that the instructions as linked above are written in security policy documents of every FIPS module we have in RHEL-6 and I do not know how much bureaucracy is needed to update the security policies of FIPS modules.

Just a little history here:

NSS can (and does) go into FIPS mode even when system-wide FIPS mode is not enabled. This is because the NSS FIPS mode is a long time feature of NSS which applications (particularly Firefox) expect to be able to use on it's own. This means NSS needs to handle the prelink case. Previously we handled the prelink case by preventing softoken and freebl from being prelinked at all. For NSS proper this wasn't a problem since NSS simply dynamically loaded both libraries on the fly, so NSS and callers of NSS could by prelinked. Unfortunately glibc used the private freebl interface and directly linked to freebl (rather than dynamically linked). After much back and forth, I was pretty much told I had to handle prelink. I call /usr/sbin/prelink -u - o - to get the actual library. If /usr/sbin/prelink does not exist, I simply open the shared library (that's why uninstalling prelink makes things work).

It seems that that's the best option, but if there is an option that I can give to prelink that tell it to 'unlink if it's linked, otherwise just output the file to standard out', we can cause NSS to change how it calls prelink without hurting the FIPS validation (I set the controls form calling prelink as a compile time flag we can override without changing the source code).

If this just started failing, BTW, then it's probably a change to prelink. Softoken/freebl hasn't changes since 6.3 and this code hadn't changes since 6.2.

bob

(In reply to comment #12)
ode).
> 
> If this just started failing, BTW, then it's probably a change to prelink.
> Softoken/freebl hasn't changes since 6.3 and this code hadn't changes since
> 6.2.

I suppose it is rather a change in the SELinux policy.

We did not change anything related to this problem.

Is there any thing that is actually getting written.  If we just need to allow the domains to execute prelink and 

tunable_policy(`fips_mode',`
prelink_exec(domain)
allow domain self:fifo_file manage_fifo_file_perms;
kernel_read_kernel_sysctls(domain)
')

I don't see this as all that dangerous.

The output of the prelink call is written to stdout pipe so that should be fine.

Added to F18

406578e4a720a9c1230a07e6b862f5f5cfd3edc1

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

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0314.html