Understanding the Trusted Execution environment in AIX V6

This article covers the advanced security features of IBM® AIX® V6.1, Trusted Execution environment. It educates AIX system administrators on how to ensure system integrity at run-time as well as at stand-by time. This article, which acts as a starting point to learn about the Trusted Execution environment, also covers the most commonly used commands and examples.       Introduction In system security, internal threats are considered of higher severity than external threats. In a system there are system commands, kernel extension modules, and the files that require root privileges to execute. All these govern the overall security model of the system. These are system-critical files and loss of their integrity threatens overall system security. The loss of integrity could be that you executed the ls command and instead of listing the contents of the directory, it deleted all the files present there. A worse situation could be that when you ran an integrity-compromised telnet command, it opened a telnet session to a remote machine, but at the same time, it stored your credentials (username and password) and sent them to a third party. These scenarios give rise to the demand for a secure operating system, where only the trusted binaries (or libraries/scripts/shells) are allowed to run. AIX V6.1 provides such a security feature, the Trusted Execution (TE) environment. What is Trusted Execution? Trusted Execution can be considered a collection of a set of features that supervise the integrity of the system. The Trusted Execution environment maintains a trusted database, where the trust values of the system-critical files are stored. Along with this database, the TE implements security policies that add another level to system security. These features are explained in detail in the later sections of this article. Trusted Execution environment over Trusted Computing Base Trusted Computing Base (TCB) is the security feature available with IBM AIX versions later than version 4.1. Trusted Computing Base is about periodically checking the integrity of the system, which is implemented using the cron job mechanism, so that it checks the integrity of the system after a specific time interval. Checking the integrity of the files at run time is very crucial; therefore, using the Trusted Execution is recommended. The run-time Trusted Execution verifies the various important attributes of the commands each time they are executed. The Trusted Execution environment is the advanced security feature of IBM AIX V6.1, which provides the following advantages over TCB: Trusted Computing Base is an install-time option only and to enable TCB on an existing AIX machine, you need to reinstall the entire AIX operating system. On the other hand, TE allows you to enable or disable the integrity-checking feature at any time. Trusted Execution supports the run-time integrity check whenever any command is executed, whereas the TCB mostly does the periodic checking of system integrity. In all, TE has more capabilities than what TCB provides. How to enable the Trusted Execution environment The Trusted Execution environment feature requires AIX V6.1 as the operating system. It is part the base operating system fileset bos.rte.security. Also, make sure that you have CryptoLite for C Library (CLiC) and its kernel extensions installed on it. These file sets are needed for TE to work. Use the following lslpp command to check whether CLiC and its kernel extensions are installed: bash-2.05b# lslpp -l "clic*" Fileset Level State Description --------------------------------------------------------------------- Path: /usr/lib/objrepos clic.rte.includes 4.3.0.0 COMMITTED CryptoLite for C Library Include File clic.rte.kernext 4.3.0.0 COMMITTED CryptoLite for C Kernel clic.rte.lib 4.3.0.0 COMMITTED CryptoLite for C Library clic.rte.pkcs11 4.3.0.0 COMMITTED PKCS11 Software Token Support Path: /etc/objrepos clic.rte.kernext 4.3.0.0 COMMITTED CryptoLite for C Kernel    If they are not installed, then install them using the smitty command. You can get these file sets from AIX Expansion pack CDs or download it from the AIX Web Download Pack program (See Resources for the link). After installing the file sets on the system, load them into the kernel with the following command: bash-2.05b# /usr/lib/methods/loadkclic    Once this is done, run the following command to turn on the Trusted Execution. bash-2.05b# trustchk -p te=on    Features of the Trusted Execution environment Trusted Signature Database (TSD) This database stores all the necessary information about system-critical files, including kernel extension modules or the files that require root privilege to execute. This database by default is located at /etc/security/tsd/tsd.dat. The entity (command / binary / library / script / shell) whose entry is there in the TSD is called a trusted entity and for such a trusted entity, a unique cryptographic hash and digital signature is stored. The cryptographic hash is calculated using the SHA-256 algorithm and the digital signature is generated using the RSA algorithm. For such a trusted entity, the hash value and signature are calculated and shipped as part of the their AIX installables and stored in TSD on the destination system. Let’s see the stanza of one of the trusted file: bash-2.05b# /usr/sbin/trustchk -q /usr/bin/chown /usr/bin/chown: owner = root group = bin mode = 555 type = FILE hardlinks = symlinks = size = 9598 cert_tag = 00af4b62b878aa47f7 signature = 4f5c5a0438148947b716a8fb744f50913f89c1fb38246e8cdcd017533a103aec 7ecc43b31c210b69b7915f961b440bc94124d198bfc6ef1594c62b0cdeedb8917cc08969a460 f686c8abda4cab15ccaf29a2740e5c42c862320a8a88e5073143466738affecbb3129a1689a0 d91cd1da98582425f23512dffa7590113cbca753 hash_value = 2c4e3308996ea6846e67847c47009e0d5d0516b4fed37a0e673c4b835f58958 cd91cd1da98582425f23512dffa7590113cbca753 minslabel = maxslabel = intlabel = accessauths = aix.fs.object.owner innateprivs = PV_DAC_O,PV_DAC_X,PV_FS_CHOWN inheritprivs = authprivs = secflags = FSF_EPS t_innateprivs = PV_MAC_R,PV_MAC_W,PV_MIC    Since all the above information for a trusted file is stored in TSD, securing TSD is vital. For the security of theTSD, the database can be locked using the following command: bash-2.05b# /usr/sbin/trustchk -p tsd_lock=on    Apart from the default TSD file (/etc/security/tsd/tsd.dat), an alternate database can also be referred to check the trusted file integrity (using the -F option in the above command), which can be kept at a secure location. Auditing the integrity of TSD (system integrity check) In order to perform a system integrity check, the /usr/sbin/trustchk command is used to check the integrity for all the trusted files by matching the actual file attribute values (like signature, hash, and etc.) with the values in the database. /usr/sbin/trustchk [-l] [-r] {-n | -t | -y}{filename...| ALL}    These are the command arguments that specify the system auditing modes: –n In this auditing mode, for the specified single trusted file or all files, all the discrepancies between the actual values and the values stored in TSD are reported, not fixed. –t In this auditing mode, for the specified single trusted file or all files, all the discrepancies are reported with a prompt asking whether errors should be fixed. –y In this auditing mode, for the specified single trusted file or all files, discrepancies are fixed and reported.Only a few common discrepancies can be fixed, not all. For instance, if there is a mismatch in the hash value, this mode is not going to repair that; instead it will make that file inaccessible. This mode should be used with caution, as it might make the file inaccessible if any serious discrepancy is found. Note: Along with each option, the keyword ALL can be used to check integrity of all the entries in TSD. This feature is basically a system audit that can be exercised periodically by the system administrator. In the following example, we are going check the integrity of the /usr/bin/hostname command, which is a system command and its entry is already in the TSD. -bash-2.05b# ls -l /usr/bin/hostname -r-xr-xr-x 1 bin bin 4288 Oct 05 2007 /usr/bin/hostname -bash-2.05b# trustchk -y /usr/bin/hostname -bash-2.05b#    Please note that trustchk -y did not give any messages in the above execution, which means that the command integrity is preserved. Now, replace the /usr/bin/hostname command with /usr/bin/cd command and then try to check the integrity: -bash-2.05b# cp /usr/bin/hostname /usr/bin/hostname.orig -bash-2.05b# cp /usr/bin/cd /usr/bin/hostname -bash-2.05b# /usr/sbin/trustchk -y /usr/bin/hostname Verification of attributes failed: size Verification of attributes failed: hash Verification of attributes failed: signature Verification of stanza failed: /usr/bin/hostname -bash-2.05b#    The above messages shows that the integrity of the command /usr/bin/hostname has been compromised. It is also important to notice that the mode of the /usr/bin/hostname command has been changed and it has become inaccessible. This happened because of the '-y' flag. The only solution is to remove the bad command binary and copy the new binary. -bash-2.05b# ls -l /usr/bin/hostname ---------T 1 bin bin 1457 May 29 08:09 /usr/bin/hostname -bash-2.05b#    Run-time integrity check by configuring security policies One of the crucial features of the Trusted Execution is to check the integrity of the trusted files at run time. When the run-time integrity check is enabled, the following steps are taken when you execute the command. During binary loading, the TE sub system is called by the system loader, which calculates the hash using the SHA-256 hash algorithm. Now for this same binary, the hash value stored in TSD is extracted and matched with the run-time calculated hash value. Binary will be allowed to execute if the values match. If the values don’t match, that means that either the file has been tampered with or changed. In this case, the action will be taken on the basis of the policy configured. The run-time integrity check is configured using the -p option of the trustchk command. Use the following syntax: trustchk -p { [ TE [= ON | OFF ] ] [ CHKEXEC [=ON | OFF ] ] [ CHKSHLIB [ =ON | OFF ] ] [ CHKSCRIPT [ =ON | OFF ] ] [ CHKKERNEXT [ = ON | OFF ] ] [ STOP_UNTRUSTD [ = ON | OFF ] ] [ STOP_ON_CHKFAIL [ = ON | OFF ] ] [ TEP [ = ON | OFF | PathList ] ] [ TLP [ = ON | OFF | PathList ] ] [ TSD_FILES_LOCK [ = ON | OFF ] ] [ TSD_LOCK [ = ON | OFF ] ] }    Policies for run-time integrity checking There are certain policies provided by IBM AIX V6.1 that can be configured for run-time integrity checking. These policies decide the fate of the binaries/libraries/scripts and kernel extensions for which the integrity check has failed. The following policies can be configured: TE This is the main policy that enables or disables the trusted execution functionality. Only after enabling this policy, the other policies can be realized. To activate the TE policy, execute the following command: bash-2.05b# /usr/sbin/trustchk -p te=on   CHKEXEC This policy makes sure that integrity of the trusted binaries is check during load time. CHKSHLIB The integrity of the trusted shared libraries is checked before loading them into the memory for execution. CHKSCRIPT The integrity of the trusted shell scripts is checked before loading them into the memory. CHKKERNEXt The integrity of the kernel extensions is checked before loading them into memory. STOP_UNTRUSTED This policy blocks the entities (which can be executable/libraries/scripts or kernel extensions) from loading if they are not in TSD. Hence, it works in combination with CHK* policies. For example, if CHKSCRIPT=ON and STOP_UNTRUSTED=ON, then those scripts that do not belong to TSD will not be executed. STOP_ON_CHKFAIL This policy stops the loading of the trusted files (same as the entities above) if integrity checks fail for them. It works in combination with CHK* policies. For instance, CHKEXEC=ON and STOP_ON_CHKFAIL=ON. then any executable for an integrity check has failed will not be loaded. TSD_LOCK This policy will lock the TSD and after that it will not be possible to manipulate it through the /usr/sbin/trustchk command. TSD_FILES_LOCK All the trusted files are locked and no change can be made to them once this policy is realized. TEP Using this policy, we can set the value of the trusted execution path, enable it, or disable it. The TE path is a list of directory paths separated by a colon. Once this policy is configured, then only the executables belonging to the set path are allowed to execute. TLP Like TEP, using this policy we can set the value of the trusted library path, enable, it or disable it. TLP is colon-separated directory path. Once it is enabled, then only the libraries that belong to the TLP will be loaded into the memory. The TEP and TLP are TE policies; they are different from the 'Trusted Execution Path' and 'Trusted Library Path' features that are covered in the next section. In order to use these policies, you need to turn ON the main TE policy.   Let's look at one example of how to turn on the run-time integrity check by configuring the policy TE, CHKEXEC, and STOP_ON_CHKFAIL. First, we are going to check the current status of the policies and then turn ON these policies. -bash-2.05b# /usr/sbin/trustchk -p TE CHKEXEC STOP_ON_CHKFAIL TE=OFF CHKEXEC=OFF STOP_ON_CHKFAIL=OFF -bash-2.05b# /usr/sbin/trustchk -p TE=ON CHKEXEC=ON STOP_ON_CHKFAIL=ON -bash-2.05b# /usr/sbin/trustchk -p TE CHKEXEC STOP_ON_CHKFAIL TE=ON CHKEXEC=ON STOP_ON_CHKFAIL=ON -bash-2.05b#    Now, we will run the /usr/bin/ls command (whose entry is already in the TSD), just to make sure that the command execution is permitted. -bash-2.05b# /usr/bin/ls .bash_history bin mnt tftpboot .profile dev opt tmp .rnd etc proc u .sh_history home sbin unix .vi_history lib smit.log usr admin lost+found smit.script var audit lpp smit.transaction -bash-2.05b#    Replace the /usr/bin/ls binary with the /usr/bin/chmod binary. Try to run the /usr/bin/ls command. This time, the execution should fail. See the below sequence: -bash-2.05b# cp /usr/bin/ls /usr/bin/ls.orig -bash-2.05b# cp /usr/bin/chmod /usr/bin/ls -bash-2.05b# /usr/bin/ls -bash: /usr/bin/ls: Cannot run the specified program in a trusted environment. -bash-2.05b#    Hence, the run-time integrity check is working on the system. If there are any Trojans or other viruses who changed any binary, then its execution will be denied. Trusted Execution Path and Trusted Library Path Along with the trusted commands, the TE environment also supports the Trusted Execution Path and Trusted Library Path. Also, it supports the concept of trusted shell and Secure Attention Key (SAK) as it is in the Trusted Computing Base. The Trusted Execution Path (TEP) specifies a list of trusted directory paths. Only those executables that belong to these paths are allowed to execute. To check the current list of trusted paths and the status of TEP, run the following command: bash-2.05b# /usr/sbin/trustchk -p tep TEP=OFF TEP=/usr/bin:/usr/sbin:/etc:/bin:/sbin:/sbin/helpers/jfs2:/usr/lib/instl:/usr/ccs/bin    To enable the TEP, execute the following command: bash-2.05b# /usr/sbin/trustchk -p tep=on    Once TEP is enabled, it should show something like this: bash-2.05b# /usr/sbin/trustchk -p tep TEP=ON TEP=/usr/bin:/usr/sbin:/etc:/bin:/sbin:/sbin/helpers/jfs2:/usr/lib/instl:/usr/ccs/bin    Trusted Library Path (TLP) specifies a list of trusted directory paths. Only those libraries that are in TLP are loaded in memory for execution. The status of TLP can be checked like this: bash-2.05b# /usr/sbin/trustchk -p tlp TLP=OFF TLP=/usr/lib:/usr/ccs/lib:/lib:/var/lib    To enable TLP, execute the following command: bash-2.05b# /usr/sbin/trustchk -p tep=on    When TLP is enabled, the status should show this: bash-2.05b# /usr/sbin/trustchk -p tlp TLP=ON TLP=/usr/lib:/usr/ccs/lib:/lib:/var/lib    How does Trusted Execution work? Figure 1. Overview of real-time Trusted Execution of a trusted command   The Trusted Execution can be exercised in the real-time execution of the trusted commands. Whenever a trusted command is entered at the command prompt (or for that matter, called by some script), first of all a hash is calculated by the operating system (see 2 in the figure) and the actual hash of the trusted command is extracted from the TSD (3). Only when both the hash values are matched, the execution of the command is allowed.   Conclusion The Trusted Execution environment is a much-awaited security feature offered in IBM AIX V6.1. This article takes you through the essentials of this feature, covering the basic functionality and examples. It allows AIX system administrators to hone their security skills to exploit this feature further.