Trusted Execution Concept, Environment and Example

TE (Trusted Execution) introduces a new thing to verify a systems integrity while

The Trusted Computing Base (TCB) is still available as an alternative.
It implements advance security policies, which together can be used to enhance the
Trust level of the complete system.
It enables or disables the trusted execution functionality. Only after enabling this policy,
The other policies can be realised.
Trusted Execution Path (TEP) defines a list of directories that contain the trusted
Executables. Once TEP verification is enabled, the system loader allows only binaries in
The specified paths to execute.
Trusted Library Path (TLP) has the same functionality, except that it is used to define the
Directories that contain trusted libraries of the system. Once TLP is enabled, the system
Loader allows only the libraries from this path to be linked to the binaries.
The trustchk command can be used to enable or disable the TEP or TLP, as well as set the
Colon separated path list for both, using TEP and TLP command line attributes of the trustchk
Command.

Integrity Checking Quick Reference:

TE
> System and Run-time checking.
TCB > System checking only.
System Enablement:
TE
> Enabled at any time.
TCB > Install time option.
Security Database Files:
TE
> /etc/security/tsd/tsd.dat
TCB > /etc/security/sysck.cfg
Management Commands:
TE
> trustchk
TCB > tcbck
Trusted execution Policy Management:
TE:
Enable / Disable run-time checking.
CHKEXEC:
Check integrity of executables before executing.
CHKSHLIBS:
Check integrity of shared libraries before loading.
CHKSCRIPTS:
Check integrity of shell scripts before executing.
CHKKERNEXT:
Check integrity of kernel extensions before loading.
LOCK_TSD:
Disable modification of TSD.
LOCK_TSD_FILES: Disable modification of TSD files.
STOP_UNTRUSTD: Do not load files unless in TSD.
STOP_ON_CHKFAIL:Do not load file if integrity check fails.
TEP:
Only allow execution of binaries from a defined list of directories.
TLP:
Only allow library loads from a defined list of directories.

In order for TE to work, the CryptoLight for C library (CLiC) and kernel extension
Need to be installed and loaded on your system. These filesets are included on
The AIX Expansion Pack and are provided for free. To check whether they are installed on
Your system and loaded into the kernel, run:
# 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
lic.rte.kernext 4.3.0.0 COMMITTED CryptoLite for C Kernel
clic.rte.lib 4.3.0.0 COMMITTED CryptoLite for C Library
Path: /etc/objrepos
clic.rte.kernext 4.3.0.0 COMMITTED CryptoLite for C Kernel
# genkex|grep clic
4562000 37748 /usr/lib/drivers/crypto/clickext

If the fileset is not installed, install it on your system and load it into the
Kernel once installation has completed successfully, by running:
# /usr/lib/methods/loadkclic
We actually have a database (Trusted Signature Database) that is used to store critical
Security parameters of trusted files present on the system. This database resides
At /etc/security/tsd/tsd.dat and comes with any AIX media. In TEs context,
Trusted files are files that are critical from the security perspective of a system
And if compromised can jeopardize the security of the entire system. Typically
The files that match this definition are:
- Kernel (operating system)
- All SUID root programs
- All SGID root programs
- Any program that is exclusively run by root or by a member of the system group
- Any program that must be run by the administrator while on the trusted
Communication path (for example, the ls command)
- The configuration files that control system operation
- Any program that is run with the privilege or access rights to alter the kernel
Or the system configuration files
Every trusted file should ideally have an associated stanza or a file definition
Stored in the TSD. A file can be marked as trusted by adding its definition in the
TSD using the trustchk command. This command can be used to add/delete/list
Entries from the TSD. If desired, the TSD can be locked so even root cannot
Write to it any longer. (Locking the TSD becomes immediately effective. To unlock the TSD,
A system reboot is required.

Example of ksh command in TSD db file (/etc/security/tsd/tsd.dat):

/usr/bin/ksh:
owner = bin
group = bin
mode = TCB,555
type = FILE
hardlinks = /usr/bin/sh,/usr/bin/psh,/usr/bin/tsh,/usr/bin/rksh
symlinks =
size = 294254
cert_tag = 00af4b62b878aa47f7
signature =
8e8118ec793fd4899ccc38c0f4ab88571b0488024aff80f83d0bde2380f3ae44137a26607cd5d4c5e58e02a
d1f872ca1c398f8702ad38f3a0f0a584c2061bb09de3e521840
5f1b07d80efe0be192d3333b8cd49a4ff980ce5e1f15f6b64d3b38f75d0cc6fb5ef9e7d8b410547c4018184
7c5ae980979abf3279f25c6b512178a
hash_value = f3a2e9b92e2cfc10ffb2274680c97f29742ff2dd12dda04de85544fd8c039fd8
minslabel =
maxslabel =
intlabel =
accessauths =
innateprivs =
inheritprivs =
authprivs =
t_accessauths = aix.mls.system.access.dir
t_innateprivs = PV_DAC_R,PV_DAC_X,PV_MAC_R
t_authprivs =
secflags =
To enable TSD protection, run:
# trustchk -p tsd_lock=on
# trustchk -p te=on
The TSD is immediately protected against any kind of modification then. Neither trustchk
Nor a manual edit of the file is possible:
# trustchk -d /usr/bin/ps
Error writing to database file
# echo >> /etc/security/tsd/tsd.dat
Operation not permitted.
To enable the TSD for write access again, you either need to switch off TE
Completely or set tsd_lock to off. Either way, you need to reboot in order to have
This change become active immediately:
# trustchk -p te=off
Policy in use. Changes applicable on next boot only

When blocking any untrusted shell scripts by using the CHKSCRIPT policy,
Make sure all scripts needed by your services are included in the TSD.
For example, if you are using OpenSSH, make sure the Ssshd and Ksshd start and stop
Scripts in /etc/rc.d/rc2.d are in the TSD. Otherwise, sshd will not get started
Upon reboot and not be shut down on a system shutdown:
# trustchk -p stop_untrustd=on
# trustchk -p chkscript=on
When trying to start a script with chkscript=on and that script is not included in
The TSD, its execution will be denied, regardless of its permissions, even when
Root is invoking it:
# ./foo
ksh: ./foo: 0403-006 Execute permission denied.
# ls -l foo
-rwx------- root system 17 May 10 11:51 foo
The Trusted Execution Path (TEP) defines a list of directories that contain the
Trusted executables. Once TEP verification is enabled, the system loader allows
Only binaries in the specified paths to execute., For example:
# trustchk -p tep
TEP=OFF
TEP=/usr/bin:/usr/sbin
# trustchk -p
tep=/usr/bin:/usr/sbin:/etc:/bin:/sbin:/usr/lib/instl:/usr/ccs/bin
# trustchk -p tep
TEP=OFF
TEP=/usr/bin:/usr/sbin:/etc:/bin:/sbin:/usr/lib/instl:/usr/ccs/bin
# trustchk -p tep=on
# trustchk -p tep
TEP=ON
TEP=/usr/bin:/usr/sbin:/etc:/bin:/sbin:/usr/lib/instl:/usr/ccs/bin
The Trusted Library Path (TLP) has the same functionality as TEP with the only
Difference that it is used to define the directories that contain trusted libraries of
The system. Once TLP is enabled, the system loader will allow only the libraries
From this path to be linked to the binaries.

The trustchk command can be used to enable/disable the TEP/TLP as well as to set the
Colon-separated path list for oth using TEP and TLP command-line attributes of trustchk:
# trustchk -p tlp
TLP=OFF
TLP=/usr/lib:/usr/ccs/lib:/lib:/var/lib
TLP uses a flag to control its operations: FSF_TLIB. If the file has the FSF_TLIB flag set
In its TSD stanza, then the process resulting from it will be set as a TLIB process.
Processes marked as TLIB processes can link only to *.so libraries that also have the TLIB flag set.
Note: Be careful when changing either TEP or TLP. We do not recommend removing paths from their
Default settings, which are currently set to:
TEP=/usr/bin:/usr/sbin:/etc:/bin:/sbin:/sbin/helpers/jfs2:/usr/lib/instl:/usr/ccs/bin
TLP=/usr/lib:/usr/ccs/lib:/lib:/var/lib
Doing so will most probably result in a system that will not reboot and function
properly since it cannot access necessary files and data any longer.
Quick Notes:
Perform a system check comparison with the TSD and report errors:
# trustchk -n ALL
Delete the entry for /usr/bin/ls in the TSD:
# trustchk -d /usr/bin/ls
Enable policy for checking executables listed in TSD on every load:
# trustchk -p CHKEXEC=ON
# Turn on Run-time TSD checking:
# trustchk -p TE=ON
Check the current run-time policy in effect:
# trustchk -p

Real Example:
# trustchk -p TE=ON
# trustchk -p CHKEXEC=ON
# trustchk -p STOP_UNTRUSTD=ON
# trustchk -d /usr/bin/ls # Deleting the entry of /usr/bin/ls from TSD.
# trustchk -p
TE=ON
CHKEXEC=ON
CHKSHLIB=OFF
CHKSCRIPT=OFF
CHKKERNEXT=OFF
STOP_UNTRUSTD=ON
STOP_ON_CHKFAIL=OFF
LOCK_KERN_POLICIES=OFF
TSD_FILES_LOCK=OFF
TSD_LOCK=OFF
TEP=OFF
TLP=OFF
# ls
ksh: ls: 0403-006 Execute permission denied.
# trustchk -p STOP_UNTRUSTD=OFF
# ls
.java
mfs
.sh_history
mnt
.ssh
myfs
# cp /usr/bin/who /usr/bin/who.orig
# cp /usr/bin/last /usr/bin/who
# trustchk -p STOP_ON_CHKFAIL=ON
# trustchk -p
TE=ON
CHKEXEC=ON
CHKSHLIB=OFF
CHKSCRIPT=OFF
CHKKERNEXT=OFF
STOP_UNTRUSTD=OFF
STOP_ON_CHKFAIL=ON
LOCK_KERN_POLICIES=OFF
TSD_FILES_LOCK=OFF
TSD_LOCK=OFF
TEP=OFF
TLP=OFF
# who
ksh: who: 0403-006 Execute permission denied.

# cp /usr/bin/who.orig /usr/bin/who
# who
mash
pts/0 Jan 11 21:56 (mash.test.ibm.com)
testuser
pts/1 Jan 13 18:13 (192.168.1.120)

Ahmed Mashhour
Global Subject Matter Expert, Technical AIX Lead.
ahdmashr@eg.ibm.com