Flask & SELinux

Flask was developed to work through some of the inherent problems with a MAC architecture. Traditional MAC is closely integrated with the multi-level security (MLS) model. Access decisions in MLS are based on clearances for subjects and classifications for objects, with the objective of no read-up, no write-down . This provides a very static lattice that allows the system to decide by a subject's security clearance level which objects can be read and written to. The focus of the MLS architecture is entirely on maintaining confidentiality.

The inflexible aspect of this kind of MAC is the focus on confidentiality. The MLS system does not care about integrity of data, least privilege, or separating processes and objects by their duty, and has no mechanisms for controlling these security needs. MLS is a mechanism for maintaining confidentiality of files on the system, by making sure that unauthorized users cannot read from or write to them.

Flask solves the inflexibility of MLS-based MAC by separating the policy enforcement from the policy logic, which is also known as the security server. In traditional Flask, the security server holds the security policy logic, handling the interpretation of security contexts. Security contexts or labels are the set of security attributes associated with a process or an object. Such security labels have the format of <user>:<role>:<type>, for example, system_u:object_r:httpd_exec_t. The SELinux user system_u is a standard identity used for daemons. The role object_r is the role for system objects such as files and devices. The type httpd_exec_t is the type applied to the httpd executable /usr/sbin/httpd.

Above picture shows the Flask architecture. In this operation, standard DAC has occurred, which means the subject already has gained access to the object via regular Linux file permissions based on the UID[1]. The operation can be anything: reading from or writing to a file/device, transitioning a process from one type to another type, opening a socket for an operation, delivering a signal call, and so forth.

1. A subject, which is a process, attempts to perform an operation on an object, such as a file, device, process, or socket.
2. The policy enforcement server gathers the security context from the subject and object, and sends the pair of labels to the security server, which is responsible for policy decision making.
3. The policy server first checks the AVC, and returns a decision to the enforcement server.
4. If the AVC does not have a policy decision cached, it turns to the security server, which uses the binary policy that is loaded into the kernel during initialization. The AVC caches the decision, and returns the decision to the enforcement server, that is, the kernel.
5. If the policy permits the subject to perform the desired operation on the object, the operation is allowed to proceed.

If the policy does not permit the subject to perform the desired operation, the action is denied, and one or more avc: denied messages are logged to$AUDIT_LOG, which is typically /var/log/messages in Red Hat Enterprise Linux.With the security server handling the policy decision making, the enforcement server handles the rest of the tasks. In this role, you can think of the enforcement code as being an object manager. Object management includes labeling objects with a security context, managing object labels in memory, and managing client and server labeling.

Reference:

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/SELinux_Guide/selg-chapter-0013.html