Bug 711216

Summary: RHEL6.1 Aide doesn't initialize its database when FIPS is enabled
Product: Red Hat Enterprise Linux 6 Reporter: jared jennings <jjennings>
Component: aideAssignee: Daniel Kopeček <dkopecek>
Status: CLOSED DUPLICATE QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: high Docs Contact:
Priority: high    
Version: 6.1CC: bboley, ksrot, sgrubb
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-03 14:24:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description jared jennings 2011-06-06 20:43:13 UTC
This appears to be the same issue as BZ553137, but under RHEL6.1. I have not duplicated the conditions of BZ553137 exactly, but I did trace my error using the debugger, with surprising results.

Description of problem:
When FIPS is enabled, aide cannot initialize its database

Version-Release number of selected component (if applicable):
aide-0.14-3.el6.i386
libgcrypt-1.4.5-5.el6_1.2.i686

Steps to Reproduce:
1. Boot in fips-compliant mode (fips=1 on kernel command line)
2. Run aide -i

Actual results:
* Error message on stderr:
libgcrypt selftest: binary  (0): No such file or directory
gcrypt_md_open failed
* Error message in /var/log/messages:
Jun  6 15:31:23 rhel6w-32 aide: Libgcrypt error: integrity check using `[?]' failed: No such file or directory
Jun  6 15:31:23 rhel6w-32 aide: Libgcrypt notice: state transition Self-Test => Error

Expected results:
Database initialized; no errors.


Additional info:
I installed the debuginfos and debugged with gdb, and here is what I found.

At fips.c:610, get_library_path("libgcrypt.so.11", "gcry_check_version", libpath, sizeof(libpath)) fails. (libpath is a null string at the time of the call; sizeof(libpath) is 4096.)

At fips.c:580, get_library_path calls dlopen(libname, RTLD_LAZY); libname is "libgcrypt.so.11".

Here's the interesting bit: the call to dlopen goes to a dlopen function defined at util.c:499, which just returns NULL. The comment immediately before that definition of dlopen says, "We need these dummy stubs to fool the linker into believing that we do not need them at link time."

Given that it appears this stub is what is actually called, rather than the real dlopen from libdl, the failure is unsurprising; but I do not know how to build libgcrypt properly to exclude the object code of this stub while still satisfying the linker as the comment says is necessary.

Comment 1 jared jennings 2011-06-06 20:50:18 UTC
Typed the bug number wrong: Bug #533137

Comment 2 jared jennings 2011-06-06 20:50:58 UTC
Doh!! Bug #553137, sorry for spam :(

Comment 3 Tomas Mraz 2011-06-06 21:00:21 UTC
The dlopen stub is from aide sources. This must be fixed in aide - I am not sure why aide contains these stubs though.

Comment 5 RHEL Program Management 2011-07-06 01:32:39 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

Comment 6 Karel Srot 2011-10-05 05:26:30 UTC
this is probably working with older aide-0.13.1-15.el6
see https://bugzilla.redhat.com/show_bug.cgi?id=553137#c7

Comment 8 Suzanne Logcher 2012-02-14 23:10:01 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

Comment 9 Steve Grubb 2012-04-03 14:24:18 UTC

*** This bug has been marked as a duplicate of bug 574770 ***