Bug 512275 - prelinking /usr/bin/sha512hmac causes self test to fail for non-root users
Summary: prelinking /usr/bin/sha512hmac causes self test to fail for non-root users
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: hmaccalc
Version: 5.4
Hardware: All
OS: Linux
low
low
Target Milestone: beta
: ---
Assignee: Nalin Dahyabhai
QA Contact: BaseOS QE
URL:
Whiteboard:
Depends On:
Blocks: 548438
TreeView+ depends on / blocked
 
Reported: 2009-07-17 00:00 UTC by Phil Perry
Modified: 2018-09-14 09:30 UTC (History)
10 users (show)

Fixed In Version: 0.9.6-3.el5
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 548438 (view as bug list)
Environment:
Last Closed: 2010-01-20 10:05:53 UTC
Target Upstream Version:


Attachments (Terms of Use)
Output of 'strace -f -s 128' (103.00 KB, application/x-bzip2)
2010-03-17 16:40 UTC, GV
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2010:0055 normal SHIPPED_LIVE hmaccalc bug fix update 2010-01-20 10:05:49 UTC

Description Phil Perry 2009-07-17 00:00:45 UTC
Description of problem:
prelinking /usr/bin/sha512hmac causes self test to fail when run as non-root user. This causes kernel builds to fail with fips enabled when building as a non-root user.

Version-Release number of selected component (if applicable):
(RHEL5.4beta)
hmaccalc-0.9.6-1.el5.x86_64
prelink-0.4.0-2.el5.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Install hmaccalc
2. run prelink, or leave prelink to run from cron overnight
3. attempt to rebuild a kernel with fips enabled (the default) as a non-root user.

Actual results:
kernel build fails

Expected results:
kernel build succeeds

Additional info:
This is essentially the same type of issue as reported in this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=456189

and it would seem the same solution would provide a workaround, namely to blacklist /usr/bin/sha512hmac from prelinking in /etc/prelink.conf.

This does not affect rebuilding kernels in mock.

Comment 1 Phil Perry 2009-07-17 11:32:26 UTC
An alternative workaround might be to have the hmaccalc package create /etc/prelink.conf.d/hmaccalc.conf blacklisting prelinking of the necessary components.

Comment 2 Nalin Dahyabhai 2009-07-17 18:58:10 UTC
I think it's as simple as the 'prelink' command not being in $PATH, so the trick of asking it to output the unprelinked (original) version and running the self-check over that doesn't work right.  Can you confirm whether or not
  PATH="$PATH":/usr/sbin sha512hmac /dev/null
works around it on a prelinked system?  (It does on mine, but I'd like to be sure.)

Comment 3 Phil Perry 2009-07-17 23:17:42 UTC
(In reply to comment #2)
> I think it's as simple as the 'prelink' command not being in $PATH, so the
> trick of asking it to output the unprelinked (original) version and running the
> self-check over that doesn't work right.  Can you confirm whether or not
>   PATH="$PATH":/usr/sbin sha512hmac /dev/null
> works around it on a prelinked system?  (It does on mine, but I'd like to be
> sure.)  

Yes, confirmed, you are indeed correct. Adding /usr/sbin to the users PATH causes the self test to no longer fail.

Likewise, creating a symlink to prelink in /usr/bin (or anywhere on the users PATH) also provides a workaround.

Personally I'd favour prelink blacklisting over having /usr/sbin or to a lesser extent prelink in a (non-root) users PATH, not to imply you were suggesting that as a solution.

Comment 4 Akemi Yagi 2009-07-17 23:58:28 UTC
I also think that adding /usr/bin/sha512hmac to the prelink blacklist is a reasonable solution.  If a non-root user cannot run sha512hmac without first applying a workaround, that would cause some cries down the road:

$ sha512hmac /bin/ls
SELF TEST FAILED (/usr/lib64/hmaccalc/sha512hmac.hmac)

Comment 5 Nalin Dahyabhai 2009-07-20 19:28:07 UTC
(In reply to comment #3)
> Personally I'd favour prelink blacklisting over having /usr/sbin or to a lesser
> extent prelink in a (non-root) users PATH, not to imply you were suggesting
> that as a solution.  

My suggested solution is to check for the exact path to the prelink command at build-time, and to attempt to invoke it directly using the full path whenever we need an unprelinked version of something, falling back to the current behavior of attempting to start it using $PATH.  I'm not wedded to it, but it works out to a rather straightforward change.

Comment 7 Alan Bartlett 2009-09-17 15:05:28 UTC
(In reply to comment #5)
> (In reply to comment #3)
> > Personally I'd favour prelink blacklisting over having /usr/sbin or to a lesser
> > extent prelink in a (non-root) users PATH, not to imply you were suggesting
> > that as a solution.  
> 
> My suggested solution is to check for the exact path to the prelink command at
> build-time, and to attempt to invoke it directly using the full path whenever
> we need an unprelinked version of something, falling back to the current
> behavior of attempting to start it using $PATH.  I'm not wedded to it, but it
> works out to a rather straightforward change.  

It is now coming up to two months since this problem was first identified.

Is there any movement on providing the above mentioned simple fix, please?

Comment 8 Nalin Dahyabhai 2009-09-17 17:21:59 UTC
The suggested fix was added to the upstream tree in 0.9.9, and it is being considered for inclusion in an update.

Comment 9 Alan Bartlett 2009-09-17 18:37:31 UTC
(In reply to comment #8)
> The suggested fix was added to the upstream tree in 0.9.9, and it is being
> considered for inclusion in an update.  

That is good news. Thank you for the information update.

It is always nice to know the status of a reported issue. :-)

Comment 10 Aristeu Rozanski 2009-11-20 18:44:56 UTC
Just an addition here, I'm used to do "su" and not "su -":

[root@napanee patchwork]# sha512hmac /etc/passwd
SELF TEST FAILED (/usr/lib64/hmaccalc/sha512hmac.hmac)
[root@napanee patchwork]# su -
[root@napanee ~]# sha512hmac /etc/passwd
71ea01dd284be482b864cd90a2b8520e92e95bef69400c68557d54f649c78d82a415499606115927e43029b81cc6338aaff2a026f2b796ac4dc214101804583a  /etc/passwd
[root@napanee ~]#

Comment 15 errata-xmlrpc 2010-01-20 10:05:53 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2010-0055.html

Comment 16 GV 2010-03-17 11:32:38 UTC
The workaround for hmaccalc-0.9.6-3.el5 (hmaccalc-prelink-path.patch) does not work is partition is mounted noexec.

I'm trying to compile the kernel and rpmbuild fail on:

pushd $RPM_BUILD_ROOT &&
%_hmacdir/sha512hmac %{image_install_path}/vmlinuz-$KernelVer > \
    %{image_install_path}/.vmlinuz-$KernelVer.hmac && popd

because /tmp and /var/tmp are mounted noexec:

+ echo 'Creating hmac file: /var/tmp/kernel-2.6.18-164.15.1.el5_4.CUSTOM-root/boot/.vmlinuz-2.6.18-164.15.1.el5_4.CUSTOM.hmac'
Creating hmac file: /var/tmp/kernel-2.6.18-164.15.1.el5_4.CUSTOM-root/boot/.vmlinuz-2.6.18-164.15.1.el5_4.CUSTOM.hmac
+ pushd /var/tmp/kernel-2.6.18-164.15.1.el5_4.CUSTOM-root
/var/tmp/kernel-2.6.18-164.15.1.el5_4.CUSTOM-root ~/work/rpm/BUILD/kernel-2.6.18/linux-2.6.18.x86_64
+ /usr/bin/sha512hmac boot/vmlinuz-2.6.18-164.15.1.el5_4.CUSTOM
SELF TEST FAILED (/usr/lib64/hmaccalc/sha512hmac.hmac)

Comment 17 Nalin Dahyabhai 2010-03-17 15:50:40 UTC
(In reply to comment #16)
> The workaround for hmaccalc-0.9.6-3.el5 (hmaccalc-prelink-path.patch) does not
> work is partition is mounted noexec.

That wasn't really the problem it was addressing -- the hmaccalc command had previously assumed that the "prelink" command could be found somewhere in the $PATH, which is incorrect.  If the binary had been prelinked after installation, hmaccalc wouldn't be able to ask prelink to give it a copy of itself as it had looked before prelinking against which to verify its checksum.

> I'm trying to compile the kernel and rpmbuild fail on:
> 
> pushd $RPM_BUILD_ROOT &&
> %_hmacdir/sha512hmac %{image_install_path}/vmlinuz-$KernelVer > \
>     %{image_install_path}/.vmlinuz-$KernelVer.hmac && popd
> 
> because /tmp and /var/tmp are mounted noexec:
> 
> + echo 'Creating hmac file:
> /var/tmp/kernel-2.6.18-164.15.1.el5_4.CUSTOM-root/boot/.vmlinuz-2.6.18-164.15.1.el5_4.CUSTOM.hmac'
> Creating hmac file:
> /var/tmp/kernel-2.6.18-164.15.1.el5_4.CUSTOM-root/boot/.vmlinuz-2.6.18-164.15.1.el5_4.CUSTOM.hmac
> + pushd /var/tmp/kernel-2.6.18-164.15.1.el5_4.CUSTOM-root
> /var/tmp/kernel-2.6.18-164.15.1.el5_4.CUSTOM-root
> ~/work/rpm/BUILD/kernel-2.6.18/linux-2.6.18.x86_64
> + /usr/bin/sha512hmac boot/vmlinuz-2.6.18-164.15.1.el5_4.CUSTOM
> SELF TEST FAILED (/usr/lib64/hmaccalc/sha512hmac.hmac)    

It's a little hard to read the output, but I'm not seeing the .spec file attempting to execute anything in /var/tmp or /tmp here.

When you run the command directly, does it still fail?  Can you run it under 'strace -f -s 128' and attach the output?

Comment 18 GV 2010-03-17 16:38:51 UTC
(In reply to comment #17)
> It's a little hard to read the output, but I'm not seeing the .spec file
> attempting to execute anything in /var/tmp or /tmp here.
Yes it is.
- kernel-2.6.18-164.15.1.el5.src.rpm
- kernel-2.6.spec line 9118
$RPM_BUILD_ROOT is expanded to /var/tmp/kernel-2.6.18-164.15.1.el5-root

# pushd /var/tmp
/var/tmp ~
# mount | grep tmp
/dev/sdb6 on /tmp type xfs (rw,noexec,nosuid,nodev)
tmpfs on /dev/shm type tmpfs (rw,noexec,nosuid,nodev)
/tmp on /var/tmp type none (rw,noexec,nosuid,nodev,bind)
# cp /bin/ls .
# /usr/bin/sha512hmac ls
SELF TEST FAILED (/usr/lib64/hmaccalc/sha512hmac.hmac)
# strace -f -s 128 -o ~/sha512hmac.log /usr/bin/sha512hmac ls
SELF TEST FAILED (/usr/lib64/hmaccalc/sha512hmac.hmac)
# popd
~
# 

All the above command are working if I'm running them as root or if /var/tmp is mounted with exec.

Comment 19 GV 2010-03-17 16:40:21 UTC
Created attachment 400825 [details]
Output of 'strace -f -s 128'


Note You need to log in before you can comment on or make changes to this bug.