This blog is created to address some security challenges with installing and checking efixes.
One of the good things is that most of efixes now have a signature file. This guarantees that the download was okay and the emgr efix package were not tampered with.
That is a good thing.
There is now also a “new” AIX command emgr_sec that automatically verifies the package signature before installation.
That is also a good improvement!
However there are still some challenges, in other words, work need to be done:
NIM Challenge (and created workaround):
If you are using NIM to install efixes there is no NIM based command for efix_sec.
For this you can use the method below to verify the efix before installing it.
Note: this method use the standard PSIRT public key included in AIX (since AIX 7.2 TL05 ?)
This is also a neat and proper way for verification.
Example for checking the efix package before using NIM to apply it:
Part of our script we use:
ifix_pub_key=/etc/security/certificates/AIX_PSIRT_pubkey.txt
openssl dgst -sha256 -verify $ifix_pub_key -signature ${emgr_package}/${emgr_package}.sig ${emgr_dir}/${efix} >/dev/null 2>&1
If the return code is 0 than your efix package is save to install (package matches the signature).
An alternative method would be to deploy efixes with a remote scp and ssh script to use the “new” efix_sec command.
Answer we got already via the discussion Threads:
As per our current plan, we are aiming "NIM based command for efix_sec" for the TL4 (Fall 2025).
Second challenge with HIPER fixes:
Currently HIPER fixes have no signature files for the efix packages, for instance take a look at these HIPER fix locations.
At least I could not find the .sig files there …
https://aix.software.ibm.com/aix/ifixes/ij49737/
https://www.ibm.com/support/pages/node/7131625
https://aix.software.ibm.com/aix/ifixes/ij46487/
https://aix.software.ibm.com/aix/ifixes/ij46694/
for example opening the webpage:
So how do we know if those important fixes are safe to install?
Other efixes have .sig files so that those efixes can be verified after download, and installed via the “new” efix_sec AIX command.
Security issue: for HIPER fixes are even more important to know that the efix is not tampered with after or during download and due to this the efix_sec AIX command cannot be used.
Created an IBM Idea for this please vote!
https://ideas.ibm.com/ideas/AIX-I-779
EFIX & TE tsd.dat update challenge:
Another issue with efix is that replaced (temporary) fixed binaries and libraries are not added with the right certtag and/or signature and hash_value in the tsd database for trustchk. Such approach does not allow secure checking of the content using trustchk after installation.
Short explanation why this TE update issue is so important.
For every AIX binary and Library, a cert_tag, signature and hash is added to the TE database (tsd.dat).
In this way we can proof that the binary, executable and library is built by IBM and is not modified.
See also my blog series about TE.
Example for this in more detail:
For example IJ49883s7a does replace the binary /usr/sbin/qdaemon
Before the efix was applied, the binaries are correctly signed and have a valid signature value (as it should be) in the tsd database tsd.dat, see below:
/usr/sbin/qdaemon:
owner = root
group = printq
mode = TCB,SUID,SGID,550
type = FILE
hardlinks =
symlinks =
size = 103101
cert_tag = 49424d4149583a31324331342d33314332303a324b3a41
signature = 7c1ca9efec42f3f20bd2dda6c391e3fc4e6be12a5a88293009611a0ebab073ca00bd156f91bcd6e2542b023df488178d13983f93895b872c75a06f818bc02ce6d50340cd67cc110b6cf586858720cc35d84a0eff4a6d1893b51e6f6b3fe413ef5a430856e62e39d8f4ce032be2483dbb7fb69b2582cb28cd7039d6b4cde288d92c05b2661f17b6df82d3251fa3020033e1912cca4b158b85de76fc2bd42388ba44e12410d7cbecd02a9f182b0ac5b5ac907519bf9e3d9e33b33cf355a0b2f15d266e8f80fa77d5b23fb3f9c5f0130f9696566b4a3ad4522298ebda2886bf8e14058b9c08ce62cd0ff248ce691430263999b896d68536ffefa4bc7537794cb44a
hash_value = 9ee51df3d744bbd5edb54259419b4f911f2f4978904c0d3ee413bbe1614b8b91
minslabel =
maxslabel =
intlabel =
accessauths =
innateprivs =
inheritprivs =
authprivs =
secflags =
After applying the efix this is modified to the following:
trustchk -q /usr/sbin/qdaemon
/usr/sbin/qdaemon:
type = FILE
owner = root
group = printq
mode = SUID,SGID,550
size = VOLATILE
hash_value = VOLATILE
cert_tag = VOLATILE
signature = VOLATILE
In my humble opinion this not okay! For each security efix or HIPER the efix should have the proper signature/hash values also updated/changed in the tsd.dat database and NOT set this to VOLATILE.
So if these binaries were modified after installation, you will not be able to detect that, thus the security checks via trustchk are not reliable anymore!
Why? The word VOLATILE in the tsd.dat breaks this verification and even the size of a binary is no longer checked.
In other words a trustchk -n /usr/sbin/qdaemon in the former example will always pass.
Also we cannot deliver evidence to our auditors that those binaries / libraries are save and not modified after installation.
Also created an IBM idea for this, Please Vote!
https://ideas.ibm.com/ideas/AIX-I-778
Automated download challenge for MRS site:
Another challenge we have, with efixes / packages that we need to download, is that we cannot automate downloads of the MRS site.
https://www.ibm.com/resources/mrs/assets/packageList?source=aixbp&lang=en_US
We first have to authenticate ourselves with an IBM ID a password. Sure this is a good thing, but makes it difficult to automate.
Does anyone know if we can download those packages on this site without authentication first, but via a public key / certificate or something?
We would like to automate those downloads as well, but now this seems not possible.
Answer we got already on the discussion Threads: As per our current plan, we are aiming “Automated download from MRS” for the TL4 (Fall 2025).
As you may have noticed, I like discussions and advice about those AIX security subjects. Any feedback or comments on this blog is much appreciated.