next up previous contents
Next: Policy Configuration Language Up: Security Server Previous: Interfaces for the Kernel   Contents

System Calls for Applications

Security-aware applications in the system require the ability to convert between SIDs and security contexts in order to use the extended system calls provided by the kernel object managers. Furthermore, some security-aware applications act as object managers for the abstractions managed by the application, e.g. a windowing system acts as the object manager for its windows. These applications require access to most of the security server interfaces. Consequently, the security server provides a set of system calls for security-aware applications.

The function prototypes for the security server system calls used by applications are in the include/ss.h header file in the syscalls package. Currently, the security server system calls are implemented using a separate entry point for each call. All of the calls could alternatively be implemented using a single entry point, as is done for sockets with the socketcall system call. Since the security server system calls are derived from the interfaces provided to the kernel, this subsection compares and contrasts the system call interface with the interface for the kernel.

Several of the system calls are identical to the corresponding interface: security_notify_perm, security_transition_sid, security_member_sid, security_change_sid and security_context_to_sid. These calls are not discussed further in this subsection. There are currently no system calls that correspond to the interfaces that provide SIDs for kernel objects: security_fs_sid, security_port_sid, security_netif_sid, and security_node_sid. Calls could be added for these interfaces if applications require the same information.

Two of the system calls, security_compute_av and security_sid_to_context, differ from the corresponding interface only in the way in which their parameters are passed. For each of these system calls, the function prototype is listed below followed by a description of the call and a discussion of how the call should be used by applications.

struct security_query {
        security_id_t ssid;
        security_id_t tsid;
        security_class_t tclass;
        access_vector_t requested;
struct security_response {
        access_vector_t allowed;
        access_vector_t decided;
        access_vector_t auditallow;
        access_vector_t auditdeny;
        access_vector_t notify;
        __u32 seqno;

int security_compute_av(
    struct security_query *query, 
    struct security_response *response);

The input parameters to the security_compute_av system call are provided in a struct security_query structure, and the output parameters are returned in a struct security_response structure. Like the kernel object managers, application object managers should use an AVC component to cache the results of a security_compute_av call. Like the kernel AVC component, the application AVC component must provide an interface to the security server for managing the cache as needed for policy changes. An application AVC component library has not yet been implemented.

int security_sid_to_context(
        security_id_t sid,
        security_context_t scontext,
        __u32 *scontext_len);

Whereas the security_sid_to_context interface for the kernel returns a dynamically-allocated string, the system call interface requires the application to provide a buffer for scontext and to initialize the scontext_len parameter with the size of the buffer. If the buffer is not large enough, then the scontext_len parameter is set to the correct length, -1 is returned, and errno is set to ENOSPC. In this case, the application may allocate a buffer of the specified length and invoke the call again with the new buffer.

Two other system calls, security_load_policy and security_get_sids, do not have a corresponding interface used by kernel object managers. For each of these system calls, the function prototype is listed below followed by a description of the call.

int security_load_policy(
        char *path,
        __u32 pathlen);

The security_load_policy system call loads a new policy configuration from a file containing a binary representation of the configuration. The pathlen parameter specifies the length of path, including the terminating NULL character. If pathlen is zero, then the default policy configuration file is reloaded. After the new policy configuration has been loaded, the security server invokes the avc_ss_reset interface of the AVC component.

int security_get_sids(
        security_id_t *sids, 
        __u32 *nel);

The security_get_sids system call returns the set of active SIDs. The nel parameter is initialized by the application to the number of elements in the array associated with the sids parameter, and modified on return to indicate the number of active SIDs. If the array is not large enough, then nel is set to the number of active SIDs, -1 is returned, and errno is set to ENOSPC.

next up previous contents
Next: Policy Configuration Language Up: Security Server Previous: Interfaces for the Kernel   Contents