Other trusted programming conventions

Trusted AIX® uses many other trusted programming conventions.

Redundancy
Redundancy is a useful technique for security systems. Security is seldom absolute, but is instead almost always a matter of placing a sufficient number of roadblocks in the path of anyone attempting to improperly access a system.
Non-duplication of kernel checks
It is rarely advisable for a process to perform a check that the kernel can perform. For example, a process should never read the MAC label of a file and perform the mandatory access check itself. Whenever possible, checking the kernel should perform a check.
Direct privilege checking
Programs should not attempt to determine whether they are invoked as privileged processes (for example, by examining their effective or maximum privilege vector). Instead, programs should assume they are invoked as privileged where appropriate.
Propagation of sensitive capabilities
A sensitive capability is a capability of a trusted program that could compromise the security of the system if provided to an untrusted program.
Effective root environments
Trusted programs frequently rely on correct absolute pathnames. For example, the login program relies on the /etc/security/passwd file to be the correct shadow password file.
Authentication with real and effective IDs
Trusted programs may need to use several user and group IDs that are associated with a process. It is important to understand the distinctions between these IDs and their appropriate use.
Absolute pathnames for trusted commands
Some security penetration schemes attempt to create a fake trusted program and place it in the search path of a shell-like program that is being used by an administrative or even regular user. For example, a fake copy of the passwd command can be used to capture an existing or new user password.
Directory tree structuring
Directory trees should be carefully structured to enhance the protection of critical files. The basic guideline is that directory search access should be as limiting as possible (for example, placing all publicly accessible files into directories that close to the root of the file system).
Read-only filesystems
Perhaps the ultimate in directory tree structuring is where trusted files that are seldom changed are placed on their own filesystem and mounted as read-only. This virtually ensures that their contents cannot be modified during normal system operation. This technique is often used for large collections of executable files for trusted programs.
Password handling
It is generally not a good practice for programs other than the standard system utilities to query the user for the login password. Passwords are extremely sensitive information and their handling should be tightly restricted to the few existing well-trusted system utilities.
Protection of the Trusted Computing Base (TCB)
Files that hold elements of the TCB must be protected from modification, and in some cases disclosure (reading), by untrusted programs.
Sensitivity label operations
There are trusted program guidelines for situations involving subjects or objects with different sensitivity labels.
Device drivers
There are some principles and guidelines that should be followed when creating device drivers for Trusted AIX systems. You should be familiar with the mechanisms for creating device drivers for the base system and with precautions regarding the use of these mechanisms.
Least privilege
Trusted AIX introduces the least privilege concept. Least privilige separates the once-powerful root user into a privilge mechanism with finer granularity.This division of privileges ensures that if there is a programming error or other defect in the trusted software, very little damage to system security is possible.
Auditing
Trusted AIX includes a set of commands for managing the audit trail generation and information. It is unlikely that a trusted system programmer will need to modify or add to these programs.
Covert channels
All trusted software is assumed to not participate in covert channel schemes. In addition, the software must be designed so that it cannot be utilized by untrusted software to exploit covert channels. This section defines covert channels and gives guidelines for their detection and limitation.
Programming examples
This section provides several trusted programming examples
Trusted AIX user and port security attributes
User and port security attributes are used to retrieve the clearance attributes of users and ports and compare the user's clearance attributes against the ports.
Trusted AIX system calls
System calls are provided to manipulate additional Trusted AIX functionality.
AIX C library functions
Subroutines and macros are provided to manipulate additional Trusted AIX functionality.

Parent topic: Principles of trusted software