Flask: Flux Advanced Security Kernel. A Project Report

2010

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.

Samantha Rassner, Sanjay Kumar, Luis Espinal
ECE 579S - Worcester Polytechnic Institute
9/21/2010

ECE 579S - September 2010

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

Rassner, Kumar, Espinal Page 2


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.



Client (SID –C)

Creates Client Object

Object Manager

Obj SID
SID Poly Obj SID
Obj SID Security Server

Obj
SID/ Context Map
OBJ OBJ OBJ
SID SID SID

Mbr SID
New SID
Enforcement Mbr SID Req Policy
Policy Logic
( SID,SID,Obj Type)
Label Rules

S

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.



Figure 9 - Kernel view of a SELinux LSM Module

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



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/



[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.


Flask: Flux Advanced Security Kernel. A Project Report

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Flask: Flux Advanced Security Kernel. A Project Report

Semelhante a Flask: Flux Advanced Security Kernel. A Project Report (20)

Último

Último (20)

Flask: Flux Advanced Security Kernel. A Project Report