Application Programming Interface

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.