Schlägt eine Sicherheitsregel bei der Umsetzung fehl, wird diese nicht in /etc/security/aixpert/core/appliedaixpert.xml übernommen. Damit wird die zugehörige Sicherheitseinstellung bei einem Lauf von „aixpert -c“ nicht überprüft.

Bei einer Anwendung des Sicherheits-Levels high auf ein System werden die folgenden Meldungen ausgegeben:

# 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
# 

Interessanterweise werden nur die Regeln angemahnt, deren Voraussetzungen nicht erfüllt sind. Es sind aber auch 2 Regeln bei der Anwendung fehlgeschlagen (Failedrules=2). Informationen welche beiden Regeln fehlgeschlagen sind, findet man in der Datei /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 #

Konkret sind das die Regeln hls_binaudit und hls_crontabperm. Regeln/Sicherheitseinstellungen die nicht umgesetzt werden konnten, werden nicht in /etc/security/aixpert/core/appliedaixpert.xml eingetragen und werden dementsprechend später nicht durch einen Lauf von „aixpert -c“ überprüft.

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

Daher sollte auch hier eine Überprüfung durchgeführt werden warum die Regeln nicht angewendet werden konnten und ob die zugehörige Sicherheitseinstellung wirklich nicht überwacht werden soll.

Wir schauen uns zunächst die erste Regel (hls_binaudit) an. Alle Aktionen der aixpert Skripte werden in der Log-Datei /etc/security/aixpert/log/aixpert.log mitprotokolliert. Wir suchen im Log die Stelle an der das Skript für die Regel hls_binaudit gestartet wird (Suche nach „hls_binaudit“). Bei einem Fehler wird das Skript mit „exit 1“ beendet, daher suchen wir ab der Postion mit der Zeichenkette „hls_binaudit“ nach der Zeichenkette „exit 1“. Schaut man ein paar Zeilen über der Zeile mit „exit 1“, findet man folgende Fehlermeldung:

+ 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.

Das Kommando chsec das die Default Audit-Klassen für Benutzer ändern soll, ist mit einem Fehler abgebrochen. Die Fehlermeldung ist „Check /etc/security/audit/config file“. Eine Überprüfung der Datei zeigt in unserem Fall, das der Eintrag für die Klasse cron fehlt. Damit kann chsec die Änderung auf die Klassen general, SRC, cron und tcpip nicht durchführen. Wir ergänzen die fehlende Klasse, indem wir den fehlenden Eintrag von einem anderen System übernehmen:

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

Um nicht alle Regeln wieder rückgängig und dann anschließend wieder anwenden zu müssen, erstellen wir eine kleine XML-Datei audit.xml unter /etc/security/aixpert/custom mit den folgenden beiden Regeln:

/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 # 

Wir haben hierfür die Prerequisite Regel prereqbinaudit und die Regel hls_binaudit aus /etc/security/aixpert/core/aixpertall.xml kopiert. Wir wenden nun diese Profil-Datei auf das System an:

/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 # 

Jetzt konnte die Regel hls_binaudit erfolgreich angewendet werden (Passedrules=1).

Es stellt sich dann eventuell noch die Frage welche Sicherheitseinstellung diese Regel vorgenommen hat? Ein Blick in die Konfigurationsdatei /etc/security/audit/config zeigt das eine Klasse für den AIX Security Expert erzeugt wurde und für alle Benutzer Auditing aktiviert wurde:

# 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
…
# 

Soll kein Auditing verwendet werden, dann kann der Fehler ganz oben bei der Regel hls_binaudit einfach ignoriert werden. Die Sicherheitseinstellung wird dann später mit „aixpert -c“ nicht überprüft.

Schauen wir uns noch die zweite fehlgeschlagene Regel hls_crontabperm an. Das aufgerufene Skript ist /etc/security/aixpert/bin/rootcrnjobck. Das Skript überprüft die crontab-Einträge von root darauf ob es sich um absolute Pfade handelt und stellt sicher das die aufgerufenen Kommandos keine Schreibrechte für die Gruppe oder other haben. Im Fehlerfalle wird die Variable exit_code auf 1 gesetzt. Wir suchen daher wieder in der Log-Datei /etc/security/aixpert/log/aixpert.log nach dem Regelnamen (hls_crontabperm) und dann nach der Zeichenkette „exit_code=1“. Drei Zeilen darüber findet man dann auch schon die folgende Fehlermeldung:

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

Offensichtlich wurde in der crontab von root das Shell builtin umask verwendet, welches natürlich keinen absoluten Pfad besitzt:

# 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
# 

Das regelmäßige Überprüfen der crontab von root ist natürlich äußerst sinnvoll. Daher ändern wir die beiden crontab-Einträge oben ab, und lassen die Änderung der Umask einfach weg:

# 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
# 

Auch hier erzeugen wir wieder eine kleine XML-Datei mit nur einer einzigen Regel (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 # 

Wir wenden diese Regel anschließend auf das System an:

/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 # 

Allerdings schlägt die Regel erneut fehl. Im Log finden wir dazu die folgende Meldung:

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

Das find-Kommando wurde nicht mit absolutem Pfad angegeben. Das lässt sich aber leicht korrigieren:

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

Jetzt ist auch die Anwendung der Regel erfolgreich, wie ein weiterer Lauf zeigt:

/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 # 

Genau wie bei fehlgeschlagenen Voraussetzungen sollten fehlgeschlagene Regeln überprüft werden. Man sollte auf jeden Fall feststellen welche Sicherheitseinstellung die Regel überprüfen soll und falls diese später automatisiert überprüft werden soll, muss der Fehler für das Fehlschlagen gesucht und behoben werden. Ist die Sicherheitseinstellung für das System nicht wichtig und soll daher nicht automatisiert überprüft werden, dann kann der Fehler beim Anwenden ignoriert werden.