Flexible Mandatory Access Control
By Glenn Faden on Mar 14, 2008
A new project, FMAC, has been initiated to add a security server based on the Flux Advanced Security Kernel (Flask) architecture to OpenSolaris. A press release has been issued announcing the joint effort between Sun and the National Security Agency. Several bloggers ( bvass, jimlaurent, barton808 ) have already posted comments and there seems to be significant interest in the community.
However, I think that it's prudent to look closely at these announcements rather that making assumptions about what is being proposed. Flask provides significant opportunities to customize the policies enforced in the kernel and in user space, but it's flexibility also poses configuration challenges. One of the things that makes Solaris popular is that it provides stable, backward-compatible binary and procedural interfaces. This constraint applies to all new projects including FMAC. Core Solaris features like Role-Based Access Control, Process Rights Management, and Multilevel Security must co-exist with new polices based on Flask. For this reason, the initial emphasis of the FMAC project should be to supplement these existing access control policies where they are deficient.
For example, it is difficult to restrict untrusted applications which run in a user context from modifying the files owned by that user. The related Fine-Grained Access Policy project addresses this issue by handling exceptions to access control denials that occur due to lack of privilege. In contrast, FMAC plans to pass all access control decisions through an extensible policy server which will make access decisions based on the policy defined for the security contexts of the subjects and objects.
Flask has been implemented in SELinux, SEBSD, and SEDarwin, but the level of complexity has caused many end-users to disable it. We don't want this to happen in OpenSolaris, so we will need to balance improvements in the safety of running untrusted applications while making it transparent to normal users.
Type Enforcement will be the key technology upon which such flexible policies will be based. Unlike MLS sensitivity labels, there is no inherent hierarchy associated with Types, and it is common for the Type to change when a parent executes a new application. MLS labels are static, and are associated with labeled zones in OpenSolaris. Types are also quite different from the authorizations and process rights (privileges) upon which Solaris RBAC is based. Type Enforcement rules can be used to define more flexible policies than these existing mechanisms.
The challenge facing this project will be to add value to Solaris without compromising its existing strengths. For example, the MLS policy in use today is completely invisible to applications because all conflicting resources are polyinstantiated using zones. My preference is that the FMAC project should focus on defining new policies based on Type Enforcement, while preserving the existing policies for Discretionary Access, Multilevel Security, user authorizations, and process privileges that we have today.