Typically, the SELinux mandatory access controls operate transparently to applications and users. The labeling decisions of the Flask architecture provide appropriate default behaviors so that the existing Linux application programming interface (API) calls can be left unchanged. The mandatory access controls are only visible to applications and users upon access failures, in which case they return the normal Linux error codes (e.g. EACCES, EPERM, ECONNREFUSED, ECONNRESET) for such failures. In most cases, the potential for these same error conditions already existed with the ordinary Linux kernel, so most applications should handle these conditions. Only a few controls, such as the controls on individual read and write calls, can cause access failures where an access failure was not previously possible.
Although existing applications can be used unmodified, it is desirable to provide new API calls to allow modified and new applications to be developed that have some degree of awareness of the new security features. Each SELinux kernel subsystem provides a set of new API calls that extend existing API calls with additional parameters for SIDs. The process management subsystem provides calls to get the current and old SIDs of a process, and a call to execute a program with a specified SID. The filesystem subsystem provides calls to create files with particular SIDs, calls to obtain the SIDs of files and filesystems, and calls to change the SIDs of files and file systems. The socket IPC subsystem provides calls to create sockets and messages with particular SIDs, calls to obtain the SIDs of sockets and messages, and calls to specify the desired SID for peer sockets. The same set of controls used for the existing API calls are also applied to these extended API calls, with the only difference being the use of an application-provided SID rather than a default SID.
Applications that use these new calls need to be able to convert between SIDs and security contexts. Furthermore, it is desirable to allow applications to obtain security policy decisions from the security server so that security policies can be defined that control access to application abstractions. For example, a windowing system might be enhanced to provide labeling and separation of windows, with controlled cut-and-paste between windows, or a database system might be enhanced to provide labeling and separation of individual database records maintained in a single file. Such application policy enforcers would still be controlled by the kernel mandatory access controls but could further refine the granularity of protection provided by the kernel. To support such applications, the security server provides a set of new API calls that export its services for converting between SIDs and contexts and obtaining security policy decisions. A set of controls is defined for these new API calls to ensure that the policy can control the ability to use them. An application access vector cache library could easily be created based on the SELinux kernel access vector cache implementation to provide security decision caching for applications.