Flask: Flux Advanced Security Kernel. A Project Report

Flask: Flux Advanced Security Kernel A Project Report for ECE 579S – Computer and Network Security (Dr. Richard Stanley) This report documents our research and findings on the subject of trusted and secure operating systems. In particular, we focus on the Flask operating system security architecture. Concrete implementations are studied with coverage of their implementation of trusted operating systems computing.

2010

Samantha Rassner, Sanjay Kumar, Luis Espinal ECE 579S - Worcester Polytechnic Institute

9/21/2010

ECE 579S - September 2010

Rassner, Kumar, Espinal Page 2

Table of Contents

1 The Evolution of the Distributed Operating System ............................................................................. 4

1.1 Timeline ......................................................................................................................................... 4

2 Historical Significance ........................................................................................................................... 8

3 Modern Computing Environments ....................................................................................................... 9

4 Introducing Flask ................................................................................................................................. 10

4.1 Architecture of Flask ................................................................................................................... 10

4.1.1 Object Manager .................................................................................................................. 11

4.1.2 Access Vector Cache ........................................................................................................... 13

4.1.3 Security Server .................................................................................................................... 13

5 SELinux ................................................................................................................................................ 14

5.1 Architecture ................................................................................................................................ 14

5.1.1 LSM Architecture................................................................................................................. 15

5.1.2 Kernel and User Space ........................................................................................................ 16

5.2 Capabilities .................................................................................................................................. 17

5.2.1 Policy Flexibility ................................................................................................................... 17

5.2.2 Trusted MAC/MLS ............................................................................................................... 18

5.3 Domain Transition ....................................................................................................................... 18

5.4 Additional Notes ......................................................................................................................... 20

References .................................................................................................................................................. 22

Figures

Figure 1 - The Multics Multi-User Architecture ............................................................................................ 5

Figure 2 - ARPANET in 1970 .......................................................................................................................... 6

Figure 3 - The Distributed Operating System, Mach ..................................................................................... 7

Figure 4 - The Flask Architecture ................................................................................................................ 11

Figure 5 - Labeling Operation by Object Manager ...................................................................................... 12

Figure 6 - Polyinstantiation in Flask ............................................................................................................ 13



Figure 7 - Security Context usage in SELinux. ............................................................................................. 15

Figure 8 - LSM Architecture (High Level View)............................................................................................ 16

Figure 9 - Kernel view of a SELinux LSM Module ........................................................................................ 17

Figure 10 - Elevation of access rights for changing an entry in /etc/shadow ............................................. 19

Figure 11 - Elevation of access rights (limited to least privilege) via domain transitions. .......................... 20

Examples

Example 1 - Security context format as encoded in extended attributes .................................................. 18

Example 2 - Associating a domain (user_t) to a type (bin_t) of file resources for read, execute and view

of attributes. ............................................................................................................................................... 18



1 The Evolution of the Distributed Operating

System

It is impossible to separate the development of the distributed operating system with the development

and evolution of the computer itself. From the beginning, the value of computing machines is based on

their capacity to process, and ultimately share, data. At a cost of approx $500,000 in 1946 dollars

(approximately $5.6 million in 2010 dollars), the first general purpose computer, ENIAC in 1946, was cost

prohibitive to anyone except a few research universities, like MIT, and government institutions like

NASA and the Department of Defense.

By the 1963, the innovation of components and general cost of computers came down enough so that

the field of computer science was an active area of research and development. Progress was spurned

forward with the joint proposal for ARPANET in 1967 to develop the first packet switching network – the

birth of the Internet.

The milestones of the evolution of computers and networking form the background of our discussion of

modern secure distributed operating systems. We will take a look at the timeline and pertinent events

that influence the direction of FLASK (Flux Advanced Security Kernel) architecture - you have to know

your history to understand your future.

1.1 Timeline

1946 ENIAC, the first digital general purpose computer, is completed. ENIAC is transferred to Aberdeen

Proving Ground in Aberdeen, Maryland, to perform ballistics analysis, atomic-energy calculations, and

meteorological studies among many other scientific projects.

1961 CTSS (Compatible Time Sharing System) was developed. CTSS is the first multi-user operating

system, demonstrating in 1961 four users logged in simultaneously through terminals directly connected

to the mainframe. CTSS lays the groundwork for Multics, with many of the scientists and engineers

working on both projects.

1962 J. C. R. Licklider of MIT begins discussions of networking with DARPA colleagues.

1963 CTSS is capable of connecting remote users to the mainframe via dial-up modems.

1964 Multics development begins. The foundation for UNIX architectures, Multics implements the first

operating system access control with the read-write-execute still in use today.



Figure 1 - The Multics Multi-User Architecture

1965 The first wide area network is created between MIT and SDC (System Development Corporation) in

Santa Monica is created using dedicated telephone lines and acoustic couplers. From this point on, the

computer network of ARPANET continues to expand. Common use of computers in Institutions is to

have local networks with multiple terminals, after the first WAN is demonstrated, it is not long before

additional locations are added to ARPANET.



Figure 2 - ARPANET in 1970

1970 The first version of UNIX, a scaled down and more efficient version of Multics, is released.

1972-1976 UNIX is released in C, making it usable across many different hardware platforms, and

adopted by many universities and research institutions. The built in remote user support directly

contributes to advancements in networking development. The Ethernet and TCP/IP protocols are

accepted and incorporated into UNIX.

1981 IBM launches the PC, with the MS DOS operating system, making low cost computers available to

the general public.

1986 The UNIX based Mach kernel is released. Mach consolidates the varied extensions of UNIX into an

architecture specifically designed to be a distributed operating environment. The Mach kernel is still

used today in Apple products.



Figure 3 - The Distributed Operating System, Mach

1987 The first T1 backbone installations begin. Implementing DoD security into operating systems

becomes a serious topic of discussion and development.

1988 The first commercial traffic is passed on the Internet. SDOS (Secure Distributed Operating System)

is proposed as a solution to implement DoD security across an open, unsecured network.

1989 Http is invented in Switzerland, creating a method to distribute information across the network

that is machine independent.

1992 Mosaic, the first web browser and precursor to Netscape, is released and the WWW explosion

begins.

1998 NSA recognizes shortcomings in available secure operating systems and sponsors a project with

the University of Utah to develop a modern and flexible distributed system architecture that could

support the stringent information security requirements of the Department of Defense.

1999 NSA introduces the Flask (Flux Advanced Security Kernel) architecture, which becomes the

foundation of security in Linux and accepted as the industry standard for security.



2 Historical Significance

In the early days of computer research and development, the machines were so size and cost prohibitive

that the physical location of the machines that were available at universities and research institutions

were well protected and extremely secured. There was no access control implemented in the early

operating systems because the only access control needed was access to the actual room where the

computers were located.

As advancements in computer hardware and software made the machines more accessible, access

control in the operating system became a necessity. It was not uncommon to have terminals remote

from the mainframes; the first security concern became user identification and authentication. Multics

integrates support for user login and access control on each file in the system. UNIX inherits the read-

write-execute access control design. Even though there were login capabilities, in the period of 1970s –

1980s, where the people using the computers were the ones doing the development and research,

security was not a concern and often password (including the password for root) were not used. The

authentication was mostly used for process ownership rather than verifying a user’s credentials.

At this time, the development and research was being performed in many universities across the nation,

with each of the teams making their own modifications to the UNIX kernel, extending the functionality

for their own purposed. The most notable university version of UNIX (and still in use) is that produced by

the University of California at Berkley, called BSD (Berkley Software Distribution). The Mach (circa 1986)

distributed system architecture is based on the 4.3BSD kernel. While lots of thought and design were

put into the client-server architecture to isolate the kernel from the implementation of the applications

accessing remote servers, so that the Mach machines operate seamlessly across a network, there was

no design for security. The mention of security in the Mach whitepaper briefly mentions maintaining

access control permissions across the network nodes and ensuring the port to port connection between

the processes on the host and server.

While the Mach kernel provided a foundation for distributed system design, it was SDOS, based on the

CRONUS military distributed operating system, that was one of the first operating systems to implement

the DoD security policies based on the Bell-LaPadula and Biba models. It is SDOS, introduced in 1988,

which begins to address the impact of the Internet on the security of a system and the difficulty the

security models introduce into the design. The difficulties begin with the designing and implementing a

trusted computing base (TCB), a secure kernel and small subset of trusted managers, on a single host –

such as not violating the security models when a high security process requests access to low security

data files when multi-level security systems are in consideration. The difficulty of maintaining security

integrity on a single host is now exasperated by the fact that the distributed trusted computing base

(DTCB) has partitions that reside in each host; each security decision now has to take into consideration

not only the host system state but also that of the servers. Also, the DTCBs have to ensure protection of

the data during transmission, so the system now needs a cryptographic engine and the system

administrators need to implement key management. Once the system is running, there is now a

problem of data synchronization, especially when security classifications of objects are changed. SDOS

attempted to answer these questions.



A 1989 analysis of the two most popular secure distributed systems, SDOS and TMach (Trusted Mach),

showed that the accepted implementations both had similar systemic security issues. Mainly, the access

control implementation in a distributed manner, and the fact that the network connections are

inherently insecure posed the largest problems. The mandatory access control issues stem from the

partitioning of the DTCB and the dynamic addition and deletions of hosts to the network both violate

the Bell-LaPadula model and enable additional avenues of covert channels through multicast messages

during this process. Security vulnerabilities are also introduced in where the access control checks are

performed and the synchronization of the access control information across the network.

Once computers and the Internet were available to the general public, security became a forefront

issues since it directly impacted consumers and sales. In addition, now that the Internet is public, that

meant exposure to hackers, enemy countries, anyone wishing to steal information or cause havoc.

Commercial antivirus software, firewalls, secure systems became hot commodities. So, the systems

which used to be safe in the hands of a limited number of university developers were now vulnerable

and needed strong security to survive in the consumer market. The systems that originally hit the public

internet in the early 90s look nothing like the “hardened” systems of today, with standard encryption

and security features like SSL, TLS, IPSec, WPA2, and Kerberos to name a few.

3 Modern Computing Environments

By the end of the 1990s there were many options for secure operating systems. FreeBSD, Linux, Solaris,

HP-UX, among others, offered advanced user access control, encryption, network security, and many

other features. But, were they sufficient to provide a solution to the questions posed by SDOS and

Tmach? Had security finally caught up to utility since the days in the 60s and 70s when it was neglected

in the university labs?

In 1998, a team from the National Security Agency (NSA) analyzed the most secure systems of that

time. While many of the systems provided a full suite of security features and there weren’t systemic

issues as in the earlier secure distributed design, there were enough issues for the team to identify a set

of “missing links” of security functionalities. Firstly, there was no commercially available kernel that

provided mandatory access security as defined by the DoD. Those systems that did attempt to

implement MAC mostly focused on the kernel and left the application space to be decided by the

application developers. The NSA team recognized the need for a commercially viable solution that not

only provided for mandatory access control in the kernel, but that also provided a uniform framework

for trusted application, and the flexibility to adapt to complex security policies. Additionally, in

mainstream systems, there were no provisions for trusted paths or protected paths. The trusted path is

a mutually authenticated channel between processes, ensuring the data is protected and critical system

functions are not being hijacked by an attacker. Additionally, mismanaged cryptographic tokens in the

system were also analyzed to be a potential vulnerability. If the service or program requesting the token

is not validated and authenticated, then there is no protection against the misuse of the cryptography

and all the data encrypted as such will be compromised. Ultimately, the systems all incorporate the

network, and while there is IPSec, SSL, and TLS to secure internet communications, they are not



invulnerable and the systems themselves are at risk to the weaknesses of the protocols they use to

communicate across the network.

The 1998 NSA analysis of the mainstream operating systems led to the definition of a new system

architecture based on security – FLASK, the Flux Advanced Security Kernel, was intended to provide a

flexible, standardized security architecture that addressed the vulnerabilities of the current systems and

provided enough flexibility to be adapted to mainstream and future use. The following sections will

review the FLASK architecture in detail and provide the implementation example of SELinux, the most

security enhanced kernel to date.

4 Introducing Flask

FLASK (Flux advanced Security Kernel) is an operating system security architecture that addresses the

need of flexibility in security policies. Flask was developed to address three key security policy

requirements. The three key flexibilities that were addressed are: controlling the propagation of access

rights, enforcing fine grained access rights and supporting the revocation of previously granted access

rights. This architecture was demonstrated by implementing a fluke Operating system micro-kernel. The

micro-kernel clearly had a dividing line implemented between the policies and their implementation. It

included a security policy server to make access control decisions. These decisions were enforced by the

object server and a framework in microkernel. The need for microkernel architecture is not a

requirement for implementing flask. The only requirement is to have a reference monitor in operating

system. Linux successfully implemented these ideas in SELinux. Details of this implementation are

described later in this paper.

The concept of controlling propagation of access rights means that the policy is consulted on every

access decision. This means that all requests for the access to objects are first checked against the

policies defined in the system. The concept of fine grained access control is implemented by integrating

the enforcement decisions into the service providing components of the system. In SELinux this idea is

implemented by a three string security identifiers that include username, role and domain. This serves

as fine grained access control implementation. The concept of revocation of the access rights is not easy

to implement. When permission is revoked the system must ensure that access is not granted to the

subject for that resource. This becomes especially challenging when revocation happens while a subject

is in middle of accessing the object. SELinux checks permissions before the access is allowed. The new

policy is enforced on later accesses.

4.1 Architecture of Flask

The three key elements of flask architecture are a object manager, security server and Access Vector

Cache (AVC). Object Manager is the enforcer of the security policy. Security server is responsible for

making security decisions. Access vector cache is speeds up policy lookup decisions. Object Manager

first consults the AVC for policy decisions and on a cache miss the request is directed to the security

server. Besides security server the decision making subsystem may also include other administrative

and policy database interfaces. Figure 4 below describes the key components of flask architecture. A



client makes a request to access an object. The request is handled by object manager. It sends the

request to security server to get a policy decision for access. The response from the Security server is

interpreted and enforced by the object Manager.

Figure 4 - The Flask Architecture

4.1.1 Object Manager

The object Manger in flask provides three primary interfaces for retrieving access, labeling and

polyinstantiation decisions from a security server. When a subject tries to access an object, the access

interfaces check if the permissions exist or not. Labeling interfaces allow assigning security attributes to

an object. Polyinstantiation decision interfaces allow access to specific member of the instantiated set of

resources. In SELinux, /tmp directory is accessible to all the processes and under that directory each

process has a specific directory that it has full access to. This is a example of polyinstantiated set of

resource (/tmp) and access to only a member of set ( /tmp/processid ).

All Objects that are controlled by security policy have a label. Label describes the security attributes and

is also called a security context. The security context is a policy independent data type and is

represented as a variable length string. In SELinux the security context is implemented as

“identity:role:domain” string. Identity is the user id and role and domain effectively provide the fine

grained access to objects. Object manager treats the security context as a opaque identifier. To make

the lookups efficient another policy independent data type called security identifier (SID) is used. It is a

32 bit number that provides mapping between SID and security context and is interpreted by security

server. Figure 2 below shows the creation and labeling of a new object. A Client with specific SID called

SID-C requests a new object to be created. The request is forwarded by Object manager to the Security

Server. The Object manager passes the Client SID, SID of the related object (if any) and the object type.

Security Server consults the policy logic to determine the security context for the new object. It returns

the SID-O, the SID that corresponds to security context for this new object. Object manger binds this SID

to the newly created Object.



Figure 5 - Labeling Operation by Object Manager

Polyinstantiation support in object manager allows for sharing of fixed resources among multiple clients.

The object manager partitions the clients into sets based on their SIDs. Object manager makes multiple

copies of a resource to share among multiple processes. Each of these instances is called members.

Figure 3 below shows that a request from client to access a polyinstantiated object. The clients SID (SID-

C) is passed along with SID of the member object and the object type. Security manager consults the

policy rules and returns the SID of the object that corresponds to the security context. The object

manager then allows access to the member specific instantiation of resource.



Creates Client Object

Mbr SID

Enforcement Mbr SID Req Policy

Client (SID –C)

Object Manager

Obj SID

SID

Obj SID

Obj

New SID

( SID,SID,Obj Type)

S

Security Server

SID/ Context Map

Policy Logic

Label Rules

OBJ

SID

OBJ

SID

OBJ

SID

Poly Obj SID

Figure 6 - Polyinstantiation in Flask

4.1.2 Access Vector Cache

When a subject makes a request to access an object, Object manager sends the request to Security

Server to return the policy decision in terms of SID of the object. The process of computing the decision

by Security server is fairly expensive. To speed up the access an “Access vector cache” notion was

introduced. The decisions sent by Security server are cached in AVC in object manager for future

reference. Once cache is populated and there is a cache hit, the decision is fairly quick and access to

security server is avoided.

4.1.3 Security Server

Security Server is a key component in flask architecture. It provides the policy decisions for object

accesses by the subjects. It provides mapping from Security context to SID. It plays a crucial role in

polyinstantiation support where it provides SIDs for member resources. It provides interfaces to load



and unload policies. The security server plays a central role in revocation of polices for a process. When

a policy is revoked or updated, it notifies the object manager, which in turn updates its internal state.

The AVC also intercepts the notification and updates or invalidates the cache for the policy that is

revoked or updated. AVC then calls the registered entry points to begin the migration of the change to

other system components. For example, when a file system would like to know when permission on a

file object has been revoked. A registered callback notifies the affected file system (system components)

of the change. Finally object manager sends a response to the Security server indicating that policy

revocation or update is complete.

5 SELinux

SELinux is a strong and flexible implementation of Flask on top of a Linux system. It provides means of

implementing MAC and MLS, and more precisely, it implements a Bell-LaPadula access model. This is

done by extending the Linux Security Modules extensions of the Linux Kernel, SELinux itself been

integrated into the mainline 2.6 series of Linux Kernels. I is becoming a standard for trusted Linux

deployments for current and future platforms (including Android [Shabial2010]).

Some of its characteristics (originating from its implementation of Flask) include a separation of

protection (enforcement) from security (policy). It also implements a reliable, trusted MAC/MLS model

via trusted channels and type enforcement. SELinux provides mechanisms for the polyinstantiation of

resources, and relies on extended attributes for implementing flexible security policies of variable

granularity and role-based access control. Most importantly, it is backward compatible. That is,

applications that run on a standard Linux distribution can run on a SELinux base without compilation

(provided security policies are in place for it.)

5.1 Architecture

SELinux being an implementation of Flask, it relies on security contexts for labeling of subjects and

objects. Everything that can be a subject (namely a process) has a security context associated to it, and

so does everything that can be accessed as a resource (namely via file handle). This is illustrated in

Figure 7.



Figure 7 - Security Context usage in SELinux.

In Figure 7, subjects requesting access to an object do so through the mediation of the Security

Enforcement Module. This in turn enforces security policies when accessing objects on the subjects’

behalf. The Security Context of each participant (as well as the SIDs) is used as input for policy

evaluation and enforcement.

5.1.1 LSM Architecture

The LSM architecture (as presented in Figure 8 [Wright2002]) illustrates the role of LSM for the

implementation of Flask architecture. After the standard DAC security evaluation takes place, a system

call is intercepted by a LSM hook which consults a Policy Engine (a LSM Module) for allowing or denying

the call to continue. What we can gather from this process is that

1. The active security model is the sum of the existing DAC and the security model(s) implemented by

the policy engine, and

2. The security model(s) implemented by the later take precedence over DAC policies.



Figure 8 - LSM Architecture (High Level View)

5.1.2 Kernel and User Space

On a SELinux system, a Flask object managers can run either in user space or in kernel space. On the

other hand, security services run in kernel/privilege space at all times. As shown in Figure 9

[Caplan2007], user-space object managers mediate access to resources via a SELinux filesystem

following the tradition of representing resources as files/file handles. The file system in turn runs within

the LSM module and closely interacts with security server.



Other object managers that reside within the kernel space must communicate with the security server

via LSM hooks. Kernel-space object managers are expected to act accordingly. That is, they are trusted

upon enforcing the access decisions computed by the security server. User-space object managers on

the other hand, implicitly enforce access decisions by returning a file handle to a resource as returned

by the SELinux filesystem (or an error if the resource is denied). In other words, enforcement of access

decisions by user-space object managers actually takes place within the SELinux filesystem. In other

words, enforcement always occurs in kernel space [Caplan2007].

5.2 Capabilities

SELinux capabilities extend to the implementation of extremely flexible security policies as well as

mechanisms for implementing trusted Bell-LaPadula security models. These are presented next.

5.2.1 Policy Flexibility

SELinux provides mechanism for flexible, variable granularity security policies by making use of file

system extended attributes as security contexts. A SELinux system (0) enforces a specific format in

Figure 9 - Kernel view of a SELinux LSM Module



extended attributes so that they represent security contexts as security labels. These labels, though

being policy-independent, are used as inputs during evaluation of security policies. Labels can be used

for defining roles, category and sensitivity (need-to-know) labels than can be associated to both subjects

(users and associated processes) and objects (any resource representable as a file handle.)

A typical security context encoded in extended attributes might take the form of the user (or domain

type label), role if any, type (when applied as an object label), and at least one category. The following is

an example:

user:role:type:sensitivity[:category,...][-sensitivity[:category,...]]

Example 1 - Security context format as encoded in extended attributes

When a category is missing, SELinux applies a default category according to the policy profile(s) in place.

In this case, either explicitly or by a given policy profile; a missing category does not provide access by

default.

5.2.2 Trusted MAC/MLS

The usage of labels in a security context is a fundamental part in the implementation of a trusted

mandatory access control and multi-level security model. For a trusted MAC/MLS to exist, SELinux

provides mechanisms for trusted paths and type enforcement [Losccoco1998]. Trusted paths, an

implementation of Flask client and server identification, are implemented at the IPC level. It ensures

that no spoofing of user or server occurs. It guarantees an absence of tampering.

Type enforcement is implemented in SELinux by providing mechanisms of least privilege. There is no

access by default; there is no notion of super user or sticky bits as implemented in standard Unix

implementations; and it gives precedence to MAC over DAC during security policy evaluation

[Caplan2007].

With type enforcement, SELinux implements a state machine that governs trusted transitions from one

operation to the next. A subject cannot perform an action on a object unless there is a relation, a

transition, between the domain (the label associated to the subject) and the type of the object (the label

associated to the object’s security context.) An example of this is found in 0.

allow user_t bin_t : file {read execute getattr};

Example 2 - Associating a domain (user_t) to a type (bin_t) of file resources

for read, execute and view of attributes.

5.3 Domain Transition

At the core of type enforcement lays the mechanism of domain transition. Just as specified in Flask, a

subject of a given domain should be able to replace its effective security context (and domain) when

executing an operation on a type. A typical example is an unprivileged login process allowing a user to

change its entry in /etc/shadow (a privileged resource.)



In typical UNIX systems, this is implemented by setting a sticky bit on the program performing the

operation, in this case /usr/bin/passwd. The net effect is that the calling, unprivileged process creates a

new process with the effective id of the passwd owner (in this case root). This elevation of access rights

is illustrated in 0 [Caplan2007]

Figure 10 - Elevation of access rights for changing an entry in /etc/shadow

The problem with this approach is that it does not follow the principle of least privilege. The new

executed process in step three (Figure 10) obtains the same access rights as root. An erroneous or

malicious change on passwd would allow it to access anything root can. This is more than what is

required, which is limited to access a single resource (/etc/shadow) for a very specific purpose (a

password change.)

With SELinux, type enforcement is used for achieving least privilege by enforcing state transitions

defined a priori in the SELinux policy profiles.



Figure 11 - Elevation of access rights (limited to least privilege) via

domain transitions.

In Figure 11 [Caplan2007], a SELinux policy defines a set of state transitions which permit a process to

change its domain to one limited for accessing the required resource and nothing more. In this example,

the user as a domain user_t associated to its security context. Furthermore, its domain is first associated

to the type associated to the /usr/bin/passwd program (in this case, passswd_exec_t).

However (and not illustrated in the figure), passwd_exec_t cannot access the desire resource

(/etc/shadow) unless it runs on a security context containing a specific passwd_t domain. A user

requires a transition from its user_t domain into the passwd_t domain to carry this operation. This is

achieved by second step of associating the passwd_t domain to the passwd_exec_t type as an entry

point. The entry point is the association that permits the domain transition to take place.

The last part of the required policy configuration is the association of the user domain (user_t) to the

passwd_t domain. This mechanism enforces the types and domains associations as well as eliminates

the need for running processes as root when accessing privilege resources.

This, in combination with trusted paths previously mentioned are the mechanisms with which SELinux

implements trusted MAC/MLS security models.

5.4 Additional Notes

LSM is a partial implementation of Flask, and as a result, same limitations apply to SELinux (or any other

implementation based on LSM architecture.) The most prominent feature missing is the ability to revoke

access rights when a process is in progress. That is, a process cannot be aborted once its access rights

are already revoked. This is a feature expected for implementation in the near future.

Other LSM-based kernel modules exist for implementing Flask. Most notably are TOMOYO Linux (in the

Linux Kernel mainline since 2.6.30); SMACK (Simplified Mandatory Access Control Kernel) and AppArmor



(available by default in Ubuntu distributions.) The main differences between these three additional LSM

modules and SELinux are that their capabilities are path-based as opposed to label-based. Furthermore,

SMACK and AppArmor purport to have easier policy configuration languages.

SELinux still remains the most commonly deployed LSM implementation despite the complexity of its

policy configurations. It remains to be seen whether it eventually adopts simpler policy configuration

languages as done by the other existing LSM modules.



References

[1] http://www.multicians.org/

[2] http://www.computerhistory.org/timeline/

[3] http://www.seas.upenn.edu/about-seas/eniac/operation.php

[4] http://library.thinkquest.org/27887/gather/history/internet.shtml

[5] P. A. Loscocco, S. D. Smalley, P. A. Muckelbauer, R. C. Taylor, S. J. Turner, and J. F. Farrell.

The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments.

In Proceedings of the 21st National Information Systems Security Conference, pages 303-314, Oct. 1998.

[6] R. Spencer, S. Smalley, P. Loscocco, M. Hibler, D. Andersen, and J. Lepreau.

The Flask Security Architecture: System Support for Diverse Security Policies.

In Proceedings of the Eighth USENIX Security Symposium, pages 123-139, Aug. 1999.

[7] A comparison of secure UNIX operating systems, Wong, R.M., Computer Security Applications

Conference, 1990., Proceedings of the Sixth Annual (0-8186-2105-2) 1990. p.333-333

[8] Issues in secure distributed operating system design., Wong, Raymond M., Digest of Papers - IEEE

Computer Society International Conference, Feb 1989. p.338-341

[9] Kain, R. Y. and Landwehr, C. E. 1987. On Access Checking in Capability-Based Systems. IEEE Trans.

Softw. Eng. 13, 2 (Feb. 1987), 202-207.

[10] Casey, T.A., Jr.; Vinter, S.T.; Weber, D.G.; Varadarajan, R.; Rosenthal, D.; , "A secure distributed

operating system," Security and Privacy, 1988. Proceedings., 1988 IEEE Symposium on , vol., no., pp.27-

38, 18-21 Apr 1988

[11] Mike Accetta, Robert Baron, William Bolosky, David Golub, Richard Rashid, Avadis Tevanian, and

Michael Young. Mach: A new kernel foundation for UNIX development. In Proceedings of the Summer

1986 USENIX Conference. pages 93-112. Atlanta, GA. June9-13. 1986.

[12] Gregory, M. and Loscocco, P. (2007) 'Using the flask security architecture to facilitate risk adaptable

access controls', Third Annual Security Enhanced Linux Symposium, National Information Assurance

Research Laboratory, 14-15 March, Wyndham Hotel, Baltimore, MD, USA,

[13] Red Hat Enterprise Linux 4: Red Hat SELinux Guide,

http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/selg-chapter-

0013.html

*14+ Jones, Tim. “Anatomy of Security-Enhanced Linux (SELinux),”

http://www.ibm.com/developerworks/linux/library/l-selinux/

http://www.multicians.org/

http://www.computerhistory.org/timeline/

http://www.seas.upenn.edu/about-seas/eniac/operation.php

http://library.thinkquest.org/27887/gather/history/internet.shtml

http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/selg-chapter-0013.html

http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/selg-chapter-0013.html




[Shabial2010] Securing Android-Powered Mobile Devices Using SELinux. Asaf Shabial, Yuval Fledel and

Yuval Elovigi, IEEE Computer and Reliability Societies, May/June 2010.

[Wright2002] Wright et al “Linux Security Module Framework”, Usenix 2002.

[Jones2008] Anatomy of Security-Enhanced Linux (SELinux) Architecture and implementation, M. Tim

Jones, Consultant Engineer, Emulex Corp. 2008. http://www.ibm.com/developerworks/linux/library/l-

selinux/

[Caplan2007] SELinux by Example, Caplan, MacMillan, Mayer. Prentice Hall, 2007

[Loscocco1998] The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing

Environments. Loscocco et al. Usenix, 1998.



Technology

Flask: Flux Advanced Security Kernel. A Project Report