AIX Security Guide

AIX OS Hardening and Security

Learn how IBM AIX provides built-in security using Trusted Computing Base (TCB), Trusted Execution (TE), aixpert hardening, and vulnerability assessment tools.

Security hardening is a core responsibility for AIX administrators on production LPARs.

IBM AIX provides multiple native security mechanisms that help protect systems against unauthorized access, malware, privilege misuse, insecure services, and configuration vulnerabilities.

Unlike many operating systems, AIX includes several built-in hardening and compliance tools directly within the OS.

Important:
  • By default, no antivirus is enabled in AIX.
  • Security hardening must be planned and implemented manually.
  • Production systems should always follow organization security policies.

1. Native Security Features in AIX

IBM AIX includes several built-in security technologies:

  • Trusted Computing Base (TCB)
  • Trusted Execution (TE)
  • aixpert Security Expert
  • Role Based Access Control (RBAC)
  • Vulnerability Assessment and Patch Validation

2. Trusted Computing Base (TCB)

Trusted Computing Base (TCB) is one of the core security frameworks available in AIX.

TCB focuses on protecting critical operating system components and controlling who can modify sensitive files, commands, configurations, and system resources.

It also introduces Role Based Access Control (RBAC) using predefined administrative roles.

Default TCB Roles:
  • isso – Information System Security Officer
  • sa – System Administrator
  • so – Security Officer

TCB Administrative Roles

Each TCB role has specific responsibilities.

  • isso: Handles password policies, audit setup, user clearance, and enterprise security configuration.
  • sa: Performs routine administration such as file system management, printer management, and standard user operations.
  • so: Responsible for reboot, shutdown, backup operations, workload management, and security-sensitive operations.

Working with TCB

Set passwords for TCB administrative users:

passwd isso
passwd sa
passwd so

Example of shutdown using the security officer role:

su - so
swrole so
shutdown -Fr

In TCB-enabled systems, direct root login is restricted.

Service not available from system accounts.

Disable and Re-enable TCB

Warning — change window required: Changing TCB_STATE via ODM is high-risk. Take a mksysb (or equivalent) backup first, test on a non-production LPAR, and plan a reboot. Do not run these commands casually on production systems.

Disable TCB (example only — verify ODM values on your release):

odmget -q attribute=TCB_STATE PdAt | \
sed 's/tcb_enabled/tcb_disabled/' | \
odmchange -o PdAt -q attribute=TCB_STATE

Re-enable TCB:

odmget -q attribute=TCB_STATE PdAt | \
sed 's/tcb_disabled/tcb_enabled/' | \
odmchange -o PdAt -q attribute=TCB_STATE
Important: TCB can only be fully enabled during OS installation. Existing systems require a Preservation Installation to enable complete TCB support. Partial ODM toggles do not restore a full install-time TCB environment.

3. Trusted Execution (TE)

Trusted Execution is a file-integrity enforcement mechanism: it verifies binaries and scripts against a Trusted Signature Database (TSD) of digitally signed trusted files. It is not antivirus or malware scanning. When TE checks are enabled, AIX validates executables/scripts against that database at run time.

Enable Trusted Execution

trustchk -p TE=ON

Enable verification of executable binaries:

trustchk -p CHKEXEC=ON

Enable verification of scripts:

trustchk -p CHKSCRIPT=ON

Block execution of untrusted binaries/scripts:

trustchk -p STOP_UNTRUSTD=ON
TE is most useful where you need enforceable integrity policy and compliance evidence — not as a substitute for patching, access control, or network controls.

4. aixpert Security Expert

aixpert is the native AIX hardening framework used to apply predefined enterprise security profiles.

It automates security configurations based on different hardening levels.

Hardening Levels

  • Low: Basic password complexity and disabling unnecessary services.
  • Medium: Stronger password policies, restricted access to system configuration files, and IP forwarding disabled.
  • High: Legacy insecure services like Telnet, FTP, rlogin, and TFTP are disabled completely.

Apply aixpert Profiles

Apply low security profile:

aixpert -l low

Apply medium security profile:

aixpert -l medium

Apply high security profile:

aixpert -l high

Check currently applied profile:

aixpert -t
aixpert configurations are cumulative. Applying a new profile layers additional security settings instead of removing previous ones.

5. Vulnerability Assessment and Penetration Testing (VAPT)

On AIX LPARs, VAPT is the periodic review that answers: what is listening, what is outdated, how far does the host deviate from a known-good baseline, and how is remote access controlled. It is an operations and security process, not a single product name.

Concrete AIX-oriented checks typically include:

  • Port and service review — inventory listeners and inetd/xinetd (or SRC) services; disable unused daemons and close unnecessary network exposure on each LPAR.
  • Patch currency via FLRTVC — run IBM FLRTVC against the LPAR (or an offline catalog) and treat HIPER/security APARs as planned change, not optional noise. See IBM FLRTVC below.
  • aixpert baseline — compare the running configuration to a documented aixpert profile (high/medium/low or a site custom profile) and remediate drift. See aixpert.
  • SSH and authentication review — confirm Telnet/rlogin are gone, SSH hardening matches policy (root login, key vs password, idle timeouts), and local/PAM or LDAP auth paths are intentional.

VAPT on AIX is not a substitute for change control, dual-VIOS planning, or application testing. It does not invent fake “AIX scanner” product names, and it does not auto-apply ifixes. Assessment finds gaps; you remediate with aixpert, FLRTVC-guided patching, TCB/TE where required, and verified configuration changes.

6. IBM FLRTVC Tool

IBM provides the FLRTVC (Fix Level Recommendation Tool Vulnerability Checker) script for AIX security analysis. Download the current script from IBM Fix Central / FLRT documentation for your release, then run it on the LPAR (network access or an offline catalog may be required depending on your site).

Typical flow:

# After placing flrtvc.ksh on the system and making it executable:
./flrtvc.ksh -e

# Review the generated CSV/HTML report for HIPER and security APARs,
# then plan ifixes / service packs in a change window.

FLRTVC helps administrators identify:

  • Missing security fixes
  • HIPER fixes
  • Outdated filesets
  • End-of-support risks
Treat FLRTVC output as input to a patch plan — not an automatic apply. Validate ifixes against your AIX level and dual-VIOS / clustered constraints before installing.

7. Security Best Practices for AIX

  • Disable unused services and ports.
  • Use SSH instead of Telnet or rlogin.
  • Apply regular security patch updates.
  • Enable auditing and logging.
  • Implement least privilege access.
  • Use RBAC wherever possible.
  • Perform regular VAPT assessments.
  • Monitor integrity using Trusted Execution.

Conclusion

AIX hardening is layered: install-time TCB where required, Trusted Execution for integrity enforcement, aixpert profiles for baseline lockdown, and FLRTVC plus regular patching for known vulnerabilities. Change TCB/TE settings only in a tested window with a recoverable backup.

Back to Articles