next up previous contents
Next: compute_av Up: Security Server Previous: Security context configuration   Contents

Prototype Implementation

This section describes the implementation of the current Linux security server prototype. The security server source code is located in the security subdirectory. In addition to being used to build the security server, this code is used in combination with policy_scan.l and policy_parse.y to build the checkpolicy program. The checkpolicy program is used to compile the policy configuration data into a binary representation for the security server. The -d option to the checkpolicy program may be used to interactively test the security server functions on a policy configuration. This option permits testing of a policy configuration prior to loading it into a running security server or prior to booting a kernel with it.

The security_init interface of the security server is implemented in init.c. This function calls policydb.c:policydb_read to create an in-memory representation of the policy configuration data (policydb.h:policydb_t) from the /ss_policy file. It then calls policydb.c:policydb_load_isids to load the initial SIDs from the policy configuration into the SID table (sidtab.h:sidtab_t). Finally, it sets a global flag, ss_initialized, to indicate that the security server has initialized.

All of the other interfaces of the security server are implemented in services.c, with the corresponding system call functions in syscalls.c. Each of the interface functions disables interrupts locally and takes a single global spin lock (ss_lock) on entry using spin_lock_irqsave, and each function uses spin_unlock_irqrestore before returning. This locking scheme is likely to change to one that uses reader-writer spinlocks, since several of the security server functions only require read access to its global data structures. Several of these functions are split into a small stub function that handles locking and a separate function with the prefix unlocked_ that implements the interface functionality. Although this separation is not currently used, it could be used to permit the security server to call one of the unlocked_ functions from another function without doubly locking.



Subsections
next up previous contents
Next: compute_av Up: Security Server Previous: Security context configuration   Contents