Flexible Mandatory Access Control

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 ( bvassjimlaurentbarton808 ) 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.



 

Comments:

Hi Glenn, long time no post :)

I am happy to see fmac going into Solaris as are others it seems. I'm glad you have started blogging about it as well, hopefully we can form a cohesive community across OS's.

I just want to comment on one point:

[[Flask has been implemented in SELinux, SEBSD, and SEDarwin, but has not yet achieved much acceptance outside of the research community.]]

I don't think this is a fair statement. The latest statistics I saw from smolt on Fedora 7 had the number of people with SELinux enabled at 50%. That number may also be low since "Don't know" was treated as no.

Welcome to the community :)

Posted by Joshua Brindle on March 17, 2008 at 03:09 AM PDT #

Sorry, I misspoke. The smolt stats were from Fedora 8, not 7. Also note that SELinux has been enabled by default on RHEL for 3 years, which is pretty compelling since its the only MAC system that can make such a claim.

Posted by Joshua Brindle on March 17, 2008 at 03:32 AM PDT #

I've removed my critical statements about SELinux since they were distracting from my main point: I want this project to combine the strengths of both architectures, rather than to be mutually exclusive.

Posted by Glenn Faden on March 17, 2008 at 04:24 PM PDT #

Hi, Glenn,

I have a question about this line:

'For example, it is difficult to restrict untrusted applications which run in a user context from modifying the files owned by that user.'

You're talking about Solaris 10 TX, right? Can you give me an example to help me to understand what you mean?

Posted by John Jesus on May 07, 2008 at 04:27 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

This blog explores some of the security features of Oracle Solaris. In particular, topics such as Role-Based Access Control and Labeled Security are my special interests.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Bookmarks