Hi, While testing RHEL-6.4 nightly in fips mode I noticed I can no longer log in. After some debugging I've figured out it has something to do with selinux and prelink. 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 /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 Here are the AVC messages from audit.log when logging in with selinux in permissive mode: type=AVC msg=audit(1353358435.317:16): avc: denied { execute } for pid=1982 comm="unix_chkpwd" name="prelink" dev=dm-0 ino=52094 scontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:prelink_exec_t:s0 tclass=file type=AVC msg=audit(1353358435.317:16): avc: denied { read open } for pid=1982 comm="unix_chkpwd" name="prelink" dev=dm-0 ino=52094 scontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:prelink_exec_t:s0 tclass=file type=AVC msg=audit(1353358435.317:16): avc: denied { execute_no_trans } for pid=1982 comm="unix_chkpwd" path="/usr/sbin/prelink" dev=dm-0 ino=52094 scontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:prelink_exec_t:s0 tclass=file type=SYSCALL msg=audit(1353358435.317:16): arch=c000003e syscall=59 success=yes exit=0 a0=7f01ca6a1940 a1=7f01ca6a1970 a2=7fff3a77fcb8 a3=7fff3a77f120 items=0 ppid=1981 pid=1982 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="prelink" exe="/usr/sbin/prelink" subj=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1353358435.317:17): avc: denied { read } for pid=1981 comm="unix_chkpwd" path="pipe:[14776]" dev=pipefs ino=14776 scontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 tclass=fifo_file type=AVC msg=audit(1353358435.317:18): avc: denied { search } for pid=1982 comm="prelink" scontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=dir type=SYSCALL msg=audit(1353358435.317:18): arch=c000003e syscall=21 success=yes exit=0 a0=4f3890 a1=0 a2=1 a3=740c4c items=0 ppid=1981 pid=1982 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="prelink" exe="/usr/sbin/prelink" subj=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1353358435.317:19): avc: denied { write } for pid=1982 comm="prelink" path="pipe:[14776]" dev=pipefs ino=14776 scontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 tclass=fifo_file type=SYSCALL msg=audit(1353358435.317:17): arch=c000003e syscall=0 success=yes exit=512 a0=3 a1=7fff3a77f550 a2=200 a3=f8 items=0 ppid=1955 pid=1981 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="unix_chkpwd" exe="/sbin/unix_chkpwd" subj=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 key=(null) type=SYSCALL msg=audit(1353358435.317:19): arch=c000003e syscall=1 success=yes exit=383504 a0=1 a1=7f1c4f697000 a2=5da10 a3=2 items=0 ppid=1981 pid=1982 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="prelink" exe="/usr/sbin/prelink" subj=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1353358435.319:20): avc: denied { setattr } for pid=1982 comm="prelink" name="" dev=pipefs ino=14776 scontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 tclass=fifo_file type=SYSCALL msg=audit(1353358435.319:20): arch=c000003e syscall=93 success=yes exit=0 a0=1 a1=0 a2=0 a3=2 items=0 ppid=1981 pid=1982 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="prelink" exe="/usr/sbin/prelink" subj=system_u:system_r:chkpwd_t:s0-s0:c0.c1023 key=(null) type=USER_AUTH msg=audit(1353358437.613:21): user pid=1955 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="hans" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=:0 res=success' I'll also attach them. Regards, Hans
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