If a security rule fails during implementation, it is not copied to /etc/security/aixpert/core/appliedaixpert.xml. This means that the associated security setting is not checked when “aixpert -c” is run.

When the security level high is applied to a system, the following messages are displayed:

# aixpert -l h  
do_action(): rule(hls_tcbupdate): warning.
do_action(): Warning: Prereq failed for prereqtcb
do_action(): rule(hls_xhost): warning.
do_action(): Warning: Prereq failed for X11.Dt.ToolTalk
do_action(): rule(hls_ISSServerSensorFull): warning.
do_action(): Warning: Prereq failed for prereqRSSSFull
do_action(): rule(hls_ISSServerSensorLite): warning.
do_action(): Warning: Prereq failed for prereqRSSSLite
Processedrules=130      Passedrules=124 PrereqFailedrules=4     Failedrules=2   Level=HLS
        Input file=/etc/security/aixpert/core/aixpertall.xml
# 

Interestingly, only those rules whose requirements are not met are warned. However, two rules also failed during application (Failedrules=2). Information about which two rules failed can be found in the file /etc/security/aixpert/log/FAILEDRULES.log:

/etc/security/aixpert # cat log/FAILEDRULES.log
do_action(): rule(prereqtcb) :Warning: Prereq failed for prereqtcb.
do_action(): rule(hls_binaudit) : failed.
do_action(): rule(hls_crontabperm) : failed.
do_action(): rule(prereqRSSSFull) :Warning: Prereq failed for prereqRSSSFull.
do_action(): rule(prereqRSSSLite) :Warning: Prereq failed for prereqRSSSLite.
/etc/security/aixpert #

Specifically, these are the hls_binaudit and hls_crontabperm rules. Rules/security settings that could not be implemented are not entered in /etc/security/aixpert/core/appliedaixpert.xml and are therefore not subsequently checked by running “aixpert -c“.

/etc/security/aixpert # grep hls_binaudit core/appliedaixpert.xml
/etc/security/aixpert # grep hls_crontabperm core/appliedaixpert.xml
/etc/security/aixpert # 

Therefore, a review should also be carried out here, to determine, why the rules could not be applied and whether the associated security setting should really not be monitored.

We’ll first look at the first rule (hls_binaudit). All actions of the aixpert scripts are logged in the log file /etc/security/aixpert/log/aixpert.log. We search the log for the point where the script for the hls_binaudit rule is started (search for “hls_binaudit“). If an error occurs, the script exits with “exit 1“, so we search for the string “exit 1” starting at the point containing the string “hls_binaudit“. If you look a few lines above the line with “exit 1“, you’ll find the following error message:

+ chsec -f /usr/lib/security/mkuser.default -s user -a auditclasses=general,SRC,cron,tcpip
Check "/etc/security/audit/config" file.
Error changing "auditclasses" to "general,SRC,cron,tcpip" : Value is invalid.

The chsec command, which was supposed to change the default audit classes for users, failed with an error. The error message is “Check /etc/security/audit/config file“. A review of the file shows that the entry for the cron class is missing. This prevents chsec from making the change to the classes general, SRC, cron and tcpip. We add the missing class by importing the missing entry from another system:

cron = AT_JobAdd,AT_JobRemove,CRON_JobAdd,CRON_JobRemove,CRON_Start,CRON_Finish

To avoid having to undo and then reapply all the rules, we create a small XML file audit.xml under /etc/security/aixpert/custom with the following two rules:

/etc/security/aixpert # cat custom/audit.xml
<?xml version="1.0" encoding="UTF-8"?>
<AIXPertSecurityHardening>
  <AIXPertEntry name="prereqbinaudit" function="prereqbinaudit">
    <AIXPertRuleType type="Prereq"/>
    <AIXPertDescription catalog="aixpert.cat" setNum="101" msgNum="1">Prereq rule for binaudit: Checks whether auditing is running or not.</AIXPertDescription>
    <AIXPertPrereqList/>
    <AIXPertCommand>/etc/security/aixpert/bin/prereqbinaudit</AIXPertCommand>
    <AIXPertArgs/>
    <AIXPertGroup/>
  </AIXPertEntry>
  <AIXPertEntry name="hls_binaudit" function="binaudit">
    <AIXPertRuleType type="HLS"/>
    <AIXPertDescription catalog="aixpert.cat" setNum="101" msgNum="68">Enable binaudit: Enables bin auditing for HLS.</AIXPertDescription>
    <AIXPertPrereqList>bos.rte,prereqbinaudit</AIXPertPrereqList>
    <AIXPertCommand>/etc/security/aixpert/bin/binaudit</AIXPertCommand>
    <AIXPertArgs>h hls_binaudit</AIXPertArgs>
    <AIXPertGroup>Audit policy recommendations</AIXPertGroup>
  </AIXPertEntry>
</AIXPertSecurityHardening>
/etc/security/aixpert # 

For this purpose, we copied the prerequisite rule prereqbinaudit and the rule hls_binaudit from /etc/security/aixpert/core/aixpertall.xml. We now apply this profile file to the system:

/etc/security/aixpert # aixpert -f custom/audit.xml
Processedrules=1        Passedrules=1   PrereqFailedrules=0     Failedrules=0   Level=HLS
        Input file=custom/audit.xml
/etc/security/aixpert # 

Now the rule hls_binaudit could be applied successfully (Passedrules=1).

This may then raise the question of which security setting this rule applies? A look at the configuration file /etc/security/audit/config shows that a class was created for the AIX Security Expert and auditing was enabled for all users:

# cat /etc/security/audit/config
…
classes:
…
        aixpert = AIXpert_apply,AIXpert_check,AIXpert_undo
…
users:
        root = root_cmd,general,SRC,mail,cron,tcpip,ipsec,lvm,aixpert
        daemon = general,SRC,cron,tcpip
…
# 

If auditing is not to be used, the error at the top of the hls_binaudit rule can simply be ignored. The security setting will then not be checked later with “aixpert -c“.

Let’s look at the second failed rule, hls_crontabperm. The script called is /etc/security/aixpert/bin/rootcrnjobck. The script checks root‘s crontab entries for absolute paths and ensures that the called commands do not have write permissions for the group or other. In the event of an error, the exit_code variable is set to 1. Therefore, we search the log file /etc/security/aixpert/log/aixpert.log again for the rule name (hls_crontabperm) and then for the string “exit_code=1“. Three lines above, you will find the following error message:

rootcrnjobck.sh: Cronjob umask is not a absolute path
+ ret=1
+ [ 1 -eq 1 ]
+ exit_code=1

Apparently, the shell builtin umask was used in root‘s crontab, which of course does not have an absolute path:

# crontab -l | grep umask
33 0 * * * umask 022 ; find /var/adm/log/nmon -name "*.nmon" -mmin +30 -exec gzip {} \\;
0 0 * * * umask 022 ; /usr/bin/nmon -ftdVSOPMN^ -s 300 -c 288 -m /var/adm/log/nmon
# 

Regularly checking root‘s crontab is, of course, extremely useful. Therefore, we’ll modify the two crontab entries above and simply omit the umask change:

# crontab -l | grep nmon
33 0 * * * find /var/adm/log/nmon -name "*.nmon" -mmin +30 -exec gzip {} \\;
0 0 * * * /usr/bin/nmon -ftdVSOPMN^ -s 300 -c 288 -m /var/adm/log/nmon
# 

Here again we create a small XML file with only one rule (hls_crontabperm):

/etc/security/aixpert # cat custom/crontab.xml
<?xml version="1.0" encoding="UTF-8"?>
<AIXPertSecurityHardening>
  <AIXPertEntry name="hls_crontabperm" function="crontabperm">
    <AIXPertRuleType type="HLS"/>
    <AIXPertDescription catalog="aixpert.cat" setNum="101" msgNum="222">Crontab permissions: Ensures root's crontab jobs are owned and writable only by root.</AIXPertDescription>
    <AIXPertPrereqList>bos.rte.date,bos.rte.shell,bos.rte.commands,bos.rte.ILS</AIXPertPrereqList>
    <AIXPertCommand>/etc/security/aixpert/bin/rootcrnjobck</AIXPertCommand>
    <AIXPertArgs>hls_crontabperm</AIXPertArgs>
    <AIXPertGroup>Miscellaneous Rules</AIXPertGroup>
  </AIXPertEntry>
</AIXPertSecurityHardening>
/etc/security/aixpert # 

We then apply this rule to the system:

/etc/security/aixpert # aixpert -f custom/crontab.xml
Processedrules=1        Passedrules=0   PrereqFailedrules=0     Failedrules=1   Level=HLS
        Input file=custom/crontab.xml
/etc/security/aixpert # 

However, the rule fails again. The log shows the following message:

rootcrnjobck.sh: Cronjob find is not a absolute path
+ ret=1
+ [ 1 -eq 1 ]
+ exit_code=1

The find command was not specified with an absolute path. This can easily be corrected:

# crontab -l | grep find
33 0 * * * /usr/bin/find /var/adm/log/nmon -name "*.nmon" -mmin +30 -exec gzip {} \\;
# 

Now the application of the rule is also successful, as another run shows:

/etc/security/aixpert # aixpert -f custom/crontab.xml
Processedrules=1        Passedrules=1   PrereqFailedrules=0     Failedrules=0   Level=HLS
        Input file=custom/crontab.xml
/etc/security/aixpert # 

Just like failed prerequisites, failed rules should be reviewed. It’s important to determine which security setting the rule is intended to check. If this setting is to be checked automatically later, the error causing the failure must be identified and resolved. If the security setting isn’t important to the system and therefore shouldn’t be checked automatically, the error can be ignored during application.