AIX

AIX

Connect with fellow AIX users and experts to gain knowledge, share insights, and solve problems.


#Power
#Power
 View Only

Runtime Verification support for library shared objects

By BUKAI Biswas posted 21 hours ago

  

Runtime Verification support for library shared objects

Introduction:

AIX 6.1 , introduced Trusted Execution (TE) function to help customers enhance the security of their environment. TE refers to a collection of features that are used to verify the integrity of the system and implement advance security policies, which together can be used to enhance the trust level of the complete system.

The usual way for a malicious user to harm the system is to get access to the system and then install Trojans, rootkits or tamper some security critical files, resulting in the system becoming vulnerable and exploitable. The central idea behind the set of features under Trusted Execution is prevention of such activities or in worst case be able to identify if any such incident happens to the system. The set of features under TE can be grouped into the following:

  • Managing Trusted Signature Database
  • Auditing integrity of the Trusted Signature Database
  • Configuring Security Policies
  • Trusted Execution Path and Trusted Library Path

Trusted Signature Database

Critical security parameters of trusted files are stored in the Trusted Signature Database (TSD) located at /etc/security/tsd/tsd.dat. Every trusted file must have an associated stanza or file definition in the TSD, which contains essential information about the file. Each trusted file is associated with a unique cryptographic hash and a digital signature:

  • The cryptographic hash of the default set of trusted files is generated using the SHA-256 algorithm.
  • The digital signature is generated using RSA by the AIX build environment during package creation as part of the AIX installation file sets.

These hash values and signatures are shipped as part of respective AIX installation images and stored in the TSD on the destination machine.

Supporting library verification

On AIX, a shared library is collection of previously link-edited object files (.o’s) or import files and is created by using the ar (archive) command. Each object file (.o) or import file within the archive (library) is referred to as a member. To support the library verification, the tsd.dat file is added in the /etc/security/tsd/lib/ directory. The name of the database is /etc/security/tsd/lib/lib.tsd.dat. This database is specifically for libraries that include the stanzas for the (.o) files of a corresponding trusted library. The stanza for every (.o) file of a library is in the format as specified in the following example. For library libc.a if the strcmp.o file is one of the (.o) file type, then the stanza for strcmp.o file in /etc/security/tsd/lib/lib.tsd.dat is similar to the following example:

Security policies configuration

The Trusted Execution (TE) feature offers a run-time file integrity verification mechanism that checks the integrity of trusted files before every request to access those files. The process ensures only trusted files that pass the integrity check are accessible. When a file is opened or executed and has an entry in the Trusted Signature Database (TSD), TE performs these steps:

  • Before loading the binary, the system loader invokes the Trusted Execution subsystem.
  • It calculates the hash value using SHA-256 algorithm (configurable) to verify the file's integrity. Alternatively, a signature can be used if the SIG_VER policy is set to ON.
  • The calculated hash value or signature is matched against the one stored in TSD.
  • If there's a match, the file access is permitted; otherwise, it indicates potential tampering or compromise.
  • Users can configure their own policies for actions when hash values or signatures don't match.
  • Based on these policies, relevant action is taken accordingly.

The following policies can be configured: CHKEXEC, CHKSHLIBS, CHKSCRIPTS, CHKKERNEXT, SIG_VER, STOP_UNTRUSTD, STOP_ON_CHKFAIL, TSD_LOCK, TSD_FILES_LOCK and TE.

For the CHKSHLIBS policy, only the security attributes listed in the /etc/security/tsd/tsd.dat database for a given library will be verified. Staring from AIX 7.3 TL4, enhancement is being done to support runtime verification of /etc/security/tsd/lib/lib.tsd.dat controlled by new trustchk policy "CHKSHOBJS".

Various use cases of the Runtime Verification for shared library objects (CHKSHOBJS) are demonstrated through the sample library path as shown below:

  • The new Trusted Execution Policy "CHKSHOBJS" can be enabled using trustchk command
  • The new Trusted Execution Policy "CHKSHOBJS" can be enabled using SMIT screen – "Change/Show characteristics of Trusted Execution".
  • The new policy "CHKSHOBJS" will be set to default value as "OFF" in the Trusted Execution Database /etc/security/tsd/tepolicies.dat as well as SMIT screen.
  • Hash verification of "/usr/ccs/lib/libaacct.a/shr.o" when TE=ON, CHKSHLIB=ON & CHKSHOBJS=ON
  • Signature verification of "/usr/ccs/lib/libaacct.a/shr.o" when TE=ON, SIG_VER=ON, CHKSHLIB=ON & CHKSHOBJS=ON
  • For secureboot, the verification of "/usr/ccs/lib/libaacct.a/shr.o"  signature will occur only if VOLATILE is set for signature field of /usr/ccs/lib/libaacct.a stanza.
  • Interaction of CHKSHOBJS with Other Policies

Enable "CHKSHOBJS" Policy

  • CHKSHOBJS policy is initially set to OFF
  • Activate CHKSHOBJS policy using the trustchk command
  • Confirm CHKSHOBJS policy status is ON

Enable CHKSHOBJS via SMIT 

  • CHKSHOBJS policy defaults to OFF
  • Access SMIT via smitty trustchk
  • Navigate to “Change/Show Characteristics of Trusted Execution”
  • Proceed to “Change/Show Current Policy Status”
  • Set Shared Object Verification (CHKSHOBJS) to ON  
  • Validate policy(CHKSHOBJS) status

Policy "CHKSHOBJS" OFF by Default in the Trusted Execution Database /etc/security/tsd/tepolicies.dat

  • CHKSHOBJS policy is initially configured as OFF in /etc/security/tsd/tepolicies.dat.
  • Enable the CHKSHOBJS policy using the trustchk command.
  • Validate that CHKSHOBJS policy is set to ON in /etc/security/tsd/tepolicies.dat.

Hash verification of "/usr/ccs/lib/libaacct.a/shr.o" when TE=ON, CHKSHLIB=ON & CHKSHOBJS=ON

  • Corrupt the hash value of the shared object /usr/ccs/lib/libaacct.a/shr.o in /etc/security/tsd/lib/lib.tsd.dat.
  • Create the trustchk_log file
  • Restart the syslogd daemon.
  • Enable policies: TE=ON, CHKSHLIB=ON, and CHKSHOBJS=ON.
  • Validate the trustchk_log file for the entry: Crypto hash verification failed: /usr/ccs/lib/libaacct.a/shr.o.

Signature verification of "/usr/ccs/lib/libaacct.a/shr.o" when TE=ON, SIG_VER=ON, CHKSHLIB=ON & CHKSHOBJS=ON

  • Corrupt the signature value of the shared object /usr/ccs/lib/libaacct.a/shr.o in /etc/security/tsd/lib/lib.tsd.dat.
  • Create the trustchk_log file
  • Restart the syslogd daemon.
  • Enable policies: TE=ON, CHKSHLIB=ON, SIG_VER=ON and CHKSHOBJS=ON.
  • Validate the trustchk_log file for the entry: Signature verification failed: /usr/ccs/lib/libaacct.a/shr.o.

For secureboot, the verification of "/usr/ccs/lib/libaacct.a/shr.o"  signature will occur only if VOLATILE is set for signature field of /usr/ccs/lib/libaacct.a stanza.

  • Confirm that the secure_boot policy is set to 1.
  • Configure the signature value of the library /usr/ccs/lib/libaacct.a as VOLATILE in /etc/security/tsd/tsd.dat.
  • Corrupt the signature value of the shared object /usr/ccs/lib/libaacct.a/shr.o
  • Reboot the system.
  • Post reboot, validate the log file /var/adm/ras/securebootlog for the entry: Secure boot: signature verification failed for /usr/ccs/lib/libaacct.a/shr.o.

Interaction of CHKSHOBJS with Other Policies

When the CHKSHOBJS policy is enabled (with Trusted Execution (TE) set to ON), its behaviour is influenced by other related policies. The table below explains how CHKSHOBJS interacts with the following policies:

  • STOP_UNTRUSTD: Determines whether shared libraries that do not belong to the Trusted Signature Database (TSD) are allowed to load.
  • STOP_ON_CHKFAIL: Controls whether shared libraries whose hash values or signatures do not match the TSD entries are blocked.

Contributors                                                                        

Mentors

Dipanjan Biswas (dipabisw@in.ibm.com)

Smita Kumari (Smita.Kumari10@ibm.com)

Madusudanan Vasudevan (madusudanan@in.ibm.com)

 Manjunath Pattanshetti (Manjunath.Pattanshetti@ibm.com)            

Kasinadh Divvela (kdivvela@in.ibm.com)

0 comments
16 views

Permalink