Kernel security tables

The information contained in the authorization, role, privileged command, and privileged device databases is not used for security considerations until the data has been loaded into an area of the kernel designated as the kernel security tables (KST). In the enhanced RBAC mode, authorization and privilege checks are performed in the kernel, so the databases must be sent to the kernel before they can be used.

All of the tables or select tables can be sent to the kernel from the user space with the setkst command. The KRT and KCT are dependent on the KAT, so if the KAT is selected to be updated, the KRT and KCT are also updated to verify that the tables are in sync. The preferred method for adding updates to the KST is to create or modify all of the necessary databases at the user level (with commands such as mkauth, chauth, mkrole, and setsecattr) and then use the setkst command to send the tables to the kernel. Once the tables have been loaded in the kernel, the lskst command can be used to display the information contained in each table.

A given table in the KST is always sent as a complete table. In other words, the KST does not allow for individual entry modifications; the entire table must be replaced. Prior to sending the tables to the kernel, the setkst command validates the tables and the relationships between them. The setkst command is also placed in the inittab file to ensure that the databases are sent to the KST early in the boot process.

If for some reason the tables cannot be created or cannot be loaded into the kernel and no tables have previously been loaded, the system operates as if there are no authorizations or roles. Commands, APIs, and system calls for authorization and role checking return failure in this scenario since no match is found. System operation in this state is very similar to the legacy RBAC mode, except that no user can access sections of code in commands that enforce authorizations.