With all the information about SELinux users and roles, we have not touched upon how exactly applications are able to create and assign a SELinux context to a user.
End users log in to a Linux system through either a login process (triggered through a getty
process), a networked service (for example, the OpenSSH daemon), or through a graphical login manager (xdm
, kdm
, gdm
, slim
, and so on).
These services are responsible for switching our effective user ID (upon successful authentication, of course) so that we are not logged on to the system as the root
user. In the case of SELinux systems, these processes also need to switch the SELinux user (and role) accordingly, as otherwise, the context will be inherited from the service, which is obviously wrong for any interactive session.
In theory, all these applications can be made fully SELinux aware, linking with the SELinux user space libraries to get information about Linux mappings and SELinux users...