History And Evolution of MAC
August 2nd, 2010 By alishinwari

1  History of Mandatory Access Control

Evolution of mandatory access control can be traced back to the early efforts Defense Science Board starting in October 1967 to enhance security that would protect classified information exposed to remote access and resource sharing. The task force presented a report named “security controls for computer systems” in February 1970 recommending a number of policy and technical actions to be taken to reduce threat to classified data accessed remotely. The DoD directive 5200.28 was published with a manual to enhance the computer systems of all defense and intelligence agencies. Research and development efforts were undertaken by Airforce, ARPA, and others to develop and demonstrate practical solutions.[1]

This work progressed to the first evaluation criteria known as Trusted Computing Security Evaluation Criteria, which is described in the next subsection.Earlier MAC implementations were Honeywell’s SCOMP [2] and NSA Blacker[3], concerned with MLS to protect military oriented security classification levels with efficient enforcement.

1.1 Trusted Computer System Evaluation Criteria (TCSEC)

TCSEC [1] is a US Government Department of Defense (DoD) standard that sets basic requirements for assessing the effectiveness of computer security controls built into a computer system. The TCSEC was used to evaluate, classify and select computer systems being considered for the processing, storage and retrieval of sensitive or classified information.
Orthogonal to DoD efforts, the National Bureau of Standards (NBS) had begun work to define issues and technical solutions for constructing, evaluating, and auditing trusted computer systems. In this work NBS conducted two workshops on audit and evaluation of security in computer systems. The main deliverable of the second workshop was a definitive document on the issues pertaining to providing standard criteria for the evaluation of technical computer system security effectiveness. MITRE Corporation began work on a set of computer security evaluation criteria that could be used to assess the degree of trust one could place in a computer system to protect classified data. This outgrowth of recommendations from the document was also supported by the DoD Computer Security Initiative. The early concepts relating to computer security evaluation were thoroughly discussed at invitational workshops and symposia, where the invited participants represented computer security experts from industry and academia in addition to the government agencies.
Other nations had started work on their own standard criteria. To standardize the criteria these national authorities joined to form what is known as the common criteria.

1.1.2 Common Criteria

The Common Criteria for Information Technology Security Evaluation[4] (Common Criteria – CC) is an international standard (ISO/IEC 15408)  for computer security certifications. The certifications are given on criteria bases. Labeled Security Protection Profile is a relevant certificate for MAC enabled systems. CC provides assurance that the process of specification, implementation and evaluation of a computer security product has been conducted in a rigorous and standard manner.

CC is a framework in which computer systems users can specify their security requirements with respect to functional and assurance goals. Then the vendors implement and define the security features of their products. The testing laboratories evaluate products to determine if they actually meet the standard minimum requirements of the certificate according to the criteria vendor claims.

2 Evolution of Mandatory Access Control

2.1  MAC on Opensource Distributions

In this section first we compare the MAC solutions on Linux based distributions in depth. Then we discuss the solutions available for other open source platforms based on BSD and Solaris. Some newer latest but maturing efforts like SMACK and Tomoyo are also touched for completeness.

2.1.2  MAC Mechanisms for the Linux Kernel

Mandatory access control on Linux platform started as patches available per solution. In order to mainstream it in the kernel an implementation independent security module was needed. This module would then be used by any MAC mechanism to register to it at a time. This modular security framework is known as the Linux security module framework.

2.1.2.1  Linux Security Module Framework
Earlier projects resorted to system call interposition to control kernel operations, which had serious limitations. [5] Secondly, there was lack for a standard mechanism and enhancements hooked to the kernel in a manner that only suited their own requirements. In addition, creating effective security module was a problematic task because the kernel had no infrastructure to mediate access of the security module to kernel objects.
To facilitate these issues the LSM[6][7] project was developed as a lightweight, general purpose, access control framework for the Linux kernel. It enables many different access control models to be implemented as loadable kernel modules. Figure 2.1 LSM Framework is a visual representation. The LSM kernel modified the kernel in five primary ways.
• It adds opaque security fields as void* pointers, which enable security modules to associate security information with kernel objects.
• It inserts calls to security hook functions at various points in kernel to mediate access to kernel objects.
• It adds generic security system calls to implement new calls for security aware applications.
• It provides functions to allow kernel modules to register and unregistered themselves as security modules.
It moves most of the capability logic into an optional security module. LSM has an important feature that is module stacking but it pushes most of the work to modules themselves. Our future study may require this feature if we are to use integrity measurements for remote attestation. LSM kernel control flow, while assessing access control rights, first checks the DAC decision and if it is positive then LSM hook gives control to hook implementation, which mediates access between kernel data structures and the decision module, else system call is returned an error code.

Figure 2.1 LSM Framework

2.1.2.2  AppArmor

AppArmor[8] previously known as SubDomain [9], is yet another implementation, which is not derived from a formal framework. It utilizes the concept of chroot jail with access control isolation enabled through program profiles. It provides a similar containment value to chroot, but without the need to physically move the application and its required resources into a separate container. AppArmor access control concentrates on file system resources, which means process transitions are not consider adequately.
AppArmor has an LSM compliant security module which is similar to SELinux in this regard. It uses LSM to communicate with securityfs, where it stores its security attributes and configurations. It uses profiles for the containment.

Figure 2.2 AppArmor Overview

2.1.2.2.1  Access Decision Mechanism

AppArmor’s decision facility is similar to SELinux as it is also LSM compliant. AppArmor is itself the core module, which handles most of the functionality. When a process invokes a system call, LSM hook implementation hooks the information from kernel data structures and provides it to the AppArmor module. Kernel data structures and identity of the subject and object, is checked against the profile of the application and reply is sent back via the hook function’s return to the system call.

2.1.2.2.2  Access Enforcement Mechanism

AppArmor earlier used system call modifications to check the confinement of processes. Now it uses the LSM module to perform these tasks. LSM is the leveraging medium between AppArmor module, system calls and kernel data structures.

2.1.2.2.3  Security Attributes and Policy Store

AppArmor uses securityfs, normally mounted on /sys/kernel/security to store its binary profile. The text files that make up the profile are parsed by apparmor_parse() called by the user space /ets/apparmor.d. The parser loads the binary policy onto securityfs via a sysctl() call from where AppArmor module loads it. By convention /etc/apparmor.d/hello_world will confine hello world.

2.1.2.3 GrSecurity

GrSecurity [10] is a suite of solutions that address different shortcomings of the operating system security. Thus, it can be stated that it does not implement any framework. It is a set of patches knitted in harmony with each other. It was originally a port of the security features of Openwall [11] but with time it has grown.
Philosophy behind GrSecurity is that currently operating systems avoid, identify and fix software bugs. The history of software development has proven that there are always going to be bugs in the software no matter what security measures are taken. GrSecurity as a solution detects, prevents and contains. Detection of vulnerabilities is available through auditing and logging of attacks, prevention by PaX (address space protection) with a combination of additional techniques.

Containment is enabled through access control lists. The ACL feature incorporates MAC into this enhancement and encourages a modular design for future extensions.
GrSecurity [10] being a knit of patches does not have a well defined kernel security module because it is inserted into various parts of the kernel to address the lack of current security mechanisms. Its ACL engine acts as the decision making facility and stores the ACL policy along with RBAC extensions.

2.1.2.3.1  Access Decision Mechanism

The ACL core of GrSecurity is the decision making facility, which gets requests from its enforcement mechanism. These requests contain identity of the requesting subject and the object being accessed. It utilizes hooks similar to what LSM provides, but are much more in number as it uses access control in multiple layers.

2.1.2.3.2  Access Enforcement Mechanism

GrSecurity enforcement being similar to SELinux and AppArmor as it has hook functions to mediate the control flow but it also has additional functionality. It has to manage the various security mechanisms. These are address space layout randomization, extensive auditing capabilities, netfilter module, stealth netfilter module, enhanced trusted path execution, OpenBSD randomness features at multiple layers, enhanced chroot jail, ptrace and Glibc restriction and various others.
These require lots of hooks and other mechanisms. This is the reason why it can’t be ported to LSM activated kernels.

2.1.2.3.3  Security Attributes and Policy Store

GrSecurity attribute management for ACL module is similar to LSM in that it does not centralize them. This was necessary for the various security features it supports. It extends various kernel data structures in order to facilitate all the patches it makes to the kernel.

2.1.2.4  RSBAC

Rule Set Based Access Control [12] is an open source security extension for the Linux type kernels based on the Generalized Framework for Access Control (GFAC) [13]. The GFAC framework targeted the integration of multiple policy components. This was achieved by modularizing the framework into access control enforcement, access control decision and access control information (security attributes) facilities. Access Decision Facility (ADF) implements the MAC security policies and a metapolicy to decide whether process’ requests satisfy those policies. Access Enforcement Facility (AEF) uses the ADF decisions to enforce the operations at system call level.
RSBAC is a direct implementation of the GFAC framework. It has been extended to supports more object types, includes generic list management and network access control, contains several additional security models and supports runtime registration of decision modules and system calls for their administration. The components ADF, AEF and ACI are hard linked into the kernel.

Figure 2.3 Overview and Flow Diagram of RSBAC

2.1.2.4.1   Access Decision Framework

RSBAC’s decision facility is ADF. With every security relevant system call, called by the subject to access an object, the AEF is invoked by intercepting the call. AEF compiles a request and sends it to the ADF for decision using an abstract function with relevant request type. The request has certain parameters; desired type of functionality is known from the request type, identification of the subjects and possibly some attributes of the object. These values are extracted by the AEF from the ACI against the subject and object.
Security policies are evaluated with respect to the policy rules for the request type by the ADF. ADF consults ACI for policy rules. When these rules are determined the meta-policy is evaluated to make the decision. Meta-policy uses the set of results from different security policies present to build the final result. Meta-policy is the union of the set of decision modules present in ADF.
ADF can be split into two parts: the main part, which handles the general work and the second part being the installed modules. The general work mainly consists of handling requests from AEF, dispatching it to the modules and performing generic logging. The modules compute the actual decisions against its policies and security attributes of the subject and object.

2.1.2.4.2   Access Enforcement Mechanism

RSBAC’s AEF enforces the decision based on the decision of ADF. Either the system call is permitted to do its function or an error is returned to the process with associated control data if necessary. In case of a positive result, ADF is notified so that ACI can be updated, the ADF tells the decision modules
to update their attributes from the data structures, sends an acknowledgement to AEF and then the object is accessed normally.
As AEF is embedded in the kernel subsystems it is the only RSBAC component, which cannot be modularized. It is hooked into several locations of the existing kernel code. Every security relevant system call and pseudo file handling function is extended by two calls to ADF. One is made before the original code, which requests for a decision and one after the original code to send update information to ADF. These two security-handling calls differ by functionality with the change in request type. Thus, it cannot be ported to LSM activated kernels. It would require a lot of change and loss in flexibility to implement new policy models.
2.1.2.4.3  Security Attributes and Policy Store

RSBAC’s ACI is used to store and maintain system values and data structures (for policy modules). System values portion stores and maintains label information for subjects and objects. It implements and store the contexts and data structures that are not handled by the kernel data structures.
Persistent attributes are additionally saved in the secondary storage. Dynamic, module specific data, like roles, user groups, access control lists and other relevant information are handled separately in the data structure portion. A file descriptor cache, fdcache, is used to reduce the performance hit because of the storage on secondary storage.

2.1.2.5  SELinux

NSA SELinux’s [14] origins are found in the research of an access control framework based on Distributed Trusted Operating System (DTOS)[15] and Distributed Trusted MACH (DTMACH) [16], two MACH [17] based kernels. The resulting framework was named Flask [18], when ported to the Fluke [19] operating system. The Flask security framework is similar to GFAC where it separates the security policy decision from the enforcement mechanism.
The Security Server (SS), being the decision module, separates the policy logic with well defined interfaces for obtaining security policy decisions. The object managers are the enforcers for their specific objects (file system, process management, IPC, sockets, e.t.c.). There is an Access Vector
Cache (AVC), which is present inside the object managers. It caches access decisions for subsequent use by the object managers.
Flask being implemented on Fluke, micro kernel architecture, had to be adjusted with the monolithic design of Linux. Its implementation was a huge patch to the bare kernel, explicitly extending a lot of data structures it used internally to handle the operations concerning files, communication and other I/O. The object managers were ported as additional functionalities implemented inside the kernel subsystems. Security server is also part of the kernel now, which was originally a server in Flask.
After LSM became the standard access control farmework for the Linux kernel, SELinux adapted. Now SS is located as a LSM compliant module and kernel subsystems use the LSM features to communicate with the security server. AVC has also become centralized but an interface is provided in libselinux for user space object managers like the X server. The LSM architecture has made the SELinux design to become a bit scattered due to LSM’s coherence with the kernel.
Internal components, in addtion to SS, enforcement at kernel subsystems and AVC are network interface table (mapping of network interfaces to security contexts), network notificationcode (keep libselinux consistent with kernel module), SELinux pseudo file system (SS’s API to processes, selinuxfs) and hook functions’ implementation.
User space object managers are supported by libselinux. X server and Postgresql are already security enhanced servers. Policy Management Server (PMS), a user space feature lately added, can also be extended to a user space SS, which will reduce burden on kernel SS. Currently PMS only provides policy management in an object oriented manner but it also aims at handling a networked policy.

2.1.2.5.1 Access Decision Mechanism

SS is the decision facility for SELinux. It uses security labels to compute an access decision comparing an object’s label with the authorization level of a subject that attempts to access the object. To handle this objective there are two data types to map an object with its access rights. The security context is a string representation of the object’s rights, which is used by the SS to compute its decision against the policy. A security identifier (SID), an integer value, is mapped to the security context and is passed to the kernel subsystem for labeling of objects. The kernel subsystems pass SIDs to the SS so that it performs the translation to security context and computes the decision.

2.1.2.5.2 Access Enforcement Mechanism

The enforcement of policy decisions in SELinux, is accomplished in the kernel subsystems. When the SS returns the decision as a return to the hook function, the enforcement code either allows by letting the system call to continue or denies by returning an error code to it.
The kernel subsystems have the duty to label its objects with the SIDs passed from the security server. In case of subjects, they are non-persistent so these SIDs work fine for their data structures. But file system objects are persistent and labeling them means to release SIDs to user space. SELinux does not allow this. This problem is addressed in the next subsection.

2.1.2.5.3 Security Attributes and Policy Store

SELinux is straight forward in labeling non-persistent objects but allowing the labeling of persistent objects needs a solution. This is enabled by storing the security context in extended file system attributes (EA) [20]. These attributes are special settings stored in the vnode of the file, which is more
efficient by storing security attributes in an inode, for each file (an earlier solution), more localized manner. Although it is a logical solution but it has the limitation of which file systems can be used with SELinux. Currently ext2, ext3, ReiserFS and XFS file systems supports extended attributes.
The policy configurations are stored in selinuxfs, the pseudo file system. This is the binary policy, while the readable version is stored on secondary storage. It can be found in /etc/selinux/policy.conf. The generation of policy.conf is based on the base and loadable policy modules configurations.
Lately two new mechanisms have been introduced to with simplicity with high priority because normal desktop users find it difficult to manage the ones mentioned above. Following are work in progress and we will give a brief overview as they are not complete for our development purposes.

2.2  Other Maturing Mac mechanisms for Linux

2.2.1 SMACK

Smack [21] is a Mandatory Access Control mechanism designed to provide useful MAC while avoiding the pitfalls of its predecessors. The limitations of Bell & LaPadula are addressed by providing a scheme whereby access can be controlled according to the requirements of the system and its purpose rather than those imposed by an arcane government policy.
The complexity of Domain Type Enforcement is avoided by defining access controls in terms of the access modes already in use.

Table 2.1 Comparison of MAC mechanisms

2.2.2 Tomoyo Linux
Tomoyo Linux [22] is a path based MAC mechanism like AppArmor but it deals with domains rather than program based. The chain of execution defines the integrity of a domain from its history of execution and accesses to this domain’s resources are controlled via the behavior defined as a policy.
Tomoyo tries to avoid the complexity of SELinux by simplifying access control. The approach is to define a domain for the subject/process by a sequence of executed processes starting from the kernel, init and onwards to the subject process and associate all access rights with these domains. Tomoyo’s approach is feasible with the learning mode that it provides. It is a work in progress due to lack of tools when compared to others.

2.3   Non Linux, Opensource MAC Implementations

2.3.1 Trusted BSD

The TrustedBSD Framework for MAC [23] was first released with FreeBSD 5.0 distribution. It has matured to support policy modules that include rule-based filesystem firewall, TCP/UDP port ACLs, inter-user process controls and classic MAC policies such as MLS with compartments, Biba integrity policies.
Policy modules include cryptographic checksums on system services and utilities. SEBSD[24] policies from the NSA FLASK based on SELinux are also ported FreeBSD.
The TrustedBSD MAC Framework was released in Mac OS X as of the Leopard distribution, where it is implemented for Seatbelt and other security services. The port of the MAC Framework was accomplished as part of the SEDarwin[25], which also had a port of FLASK/SELinux to Mac OS X.

2.3.2 Trusted Solaris and FMAC

Labeled security has made it to the mainstream operating system therefore Sun Microsystems has included features of Trusted Solaris[26], such as fine-grained access control, as part of the standard Solaris 10 release. This extension is called the Solaris Trusted Extensions. It is no longer necessary maintain a different kernel for labeled security environments. Solaris Trusted Extensions is an OpenSolaris project.
Solaris Trusted Extensions enforce a MAC policy on device access, file systems, networking, print and window management services and other operating system services. Sensitivity labels are assigned to objects of services, thereby establishing explicit information flow relationships between objects. Appropriate rules allows applications and users access to the objects’ methods and properties.
Lately the Flexible MAC (FMAC) project [27] has been initiated by the openSolaris community in the leadership of NSA, which adds the Flux Advanced Security Kernel architecture and Type Enforcement to OpenSolaris.

2.3.3 MAC on mobile devices

There have been researches, commercial and individual scholarly efforts to implement MAC on mobile devices. One of the first successful attempts was made by Montavista Linux [28]. Then Willis Vanderventer also ported it for GTA01 in a Google summer of code project [29], which we have used as a base source for our GTA02 targeted porting efforts.
In this section we will dive into the innovations of MAC on mobile platforms rather than porting issues which is discussed in implementation of SELinux on Openmoko in depth. First of all we will understand what the requirements are then followed by the available solutions.
The most important role that MAC plays is to provide isolation to stakeholder engines and resources with well defined interfaces. The MPWG [30] requires resources on the platform to be organized in isolated domains with internal interfaces creating sub-domains, with limited tiers. The software stack is supposed to be considered as entities that group into engines for stakeholders’ domain of authority. Engines communicate using defined interfaces.
MAC policy ensures that the software components, entities or data are accessed in a specified and trusted manner thus enabling a framework that gives integrity to the platform and its resources.

Figure 2.4 Mobile Phone Reference Architecture

Stakeholders are the autonomous entities that the resources of the platform belong to. In the TCG MPWG model the stakeholders are categorized as the mandatory and discretionary owners with respect to the engine types. An owner can have both types of engines as well. Then we can further categorize to device manufacturer, network operator, and general service providers as remote owners and the device user as local owner.

Figure 2.5 A generic Trust Engine and its interfaces

Consider the engine, in Figure 2.5, which can access services of other engines only through interfaces (1) and (6), and provides services to others only through interfaces (2) and (5).
Zhang et al. used the SELinux to form MPRA [31] as specified by the MPWG. In this work the MAC policy controls the information flows in such a way that stakeholder engines are isolated and least privileges are provided using interfaces between engines. They have also included a binary measurement agent that is used to measure the binary integrity using SELinux file system attributes and hooks.
Yet in another work he has demonstrated to use an integrity model for access control and on a mobile platform [32]. It demonstrates how object managers can be used to enforce better integrity of the platform.
PRIMA [33] is an approach where integrity measurement has been integrated with MAC mechanism of the platform. A Clark-Wilson lite model is used to enforce integrity based on filtering subjects. The filtering subjects are the object managers.

Nokia’s research on MAC [34] for mobile platforms uses two techniques, which are very different then other related literature on this topic. The first technique is to use a pre-configured lattice-based capability system for manufacturer provided operating system and its services. The second technique is the caging for untrusted programs. Caging allows the user to run these programs in an isolated environment. A cage being a virtual entity, which controls access to file system, networking and IPC for these programs according to the caging policy defined by the user at install time.

References

  1. Trusted computer system evaluation criteria. Tcsec, DOD. s.l. : Technical Report 5200.28-STD, US Department of Defense, 1985
  2. Scomp: A solution to the multilevel security problem. Fraim, LJ. 1983. Computer
  3. Defense Data Network Security Architecture. Shirey, R.W. s.l. : ACM SIGCOMM Computer Communication Review, ACM, 1990. ACM SIGCOMM Computer Communication Review.
  4. Common Criteria for Information Security Evaluation. [Online] http://www.commoncriteriaportal.org/.
  5. Traps and pitfalls: Practical problems in system call interposition based security tools. Garfinkel, T.
  6. Linux security modules: General security support for the linux kernel. Wright, C. and Cowan, C. and Smalley, S. and Morris, J. and Kroah-Hartman, G. s.l. : Proceedings of the 11th USENIX Security Symposium, 2002
  7. Linux security module framework. Wright, C. and Cowan, C. and Morris, J. and Smalley, S. and Kroah-Hartman, G. s.l. : Ottawa Linux Symposium, 2002
  8. AppArmor Security for Linux Application. Novel. [Online] Novel Inc. http://www.novell.com/linux/security/apparmor/.
  9. Subdomain: Parsimonious server security. Cowan, C. and Beattie, S. and Kroah-Hartman, G. and Pu, C. and Wagle, P. and Gligor, V.
  10. GrSecurity Papers. GrSecuirity. [Online] http://www.grsecurity.net/papers.php.
  11. Openwall Project – Information Security Software. Openwall. [Online] http://www.openwall.com/.
  12. Documentation. Rulset Based Access Control. [Online] http://www.rsbac.org/documentation.
  13. The rule set based access control (rsbac) framework for linux. Ott, A. and Fischer-H{\\”u}bner, S. s.l. : Citeseer.
  14. Publications. NSA Security Enhanced Linux. [Online] http://www.nsa.gov/research/publications/index.shtml.
  15. Home Page. A Distributed trusted Operating System. [Online] http://www.cs.utah.edu/flux/fluke/html/dtos/HTML/dtos.html.
  16. Assuring distributed trusted mach. Fine, T. and Minear, SE. s.l. : IEEE Computer Society Symposium on Research in Security and Privacy., 1993
  17. Home Page. The MACH project. [Online] http://www-2.cs.cmu.edu/afs/cs/project/mach/public/www/mach.html.
  18. Flux Advance Security Kernel. Flask. [Online] http://www.cs.utah.edu/flux/fluke/html/flask.html.
  19. Flux Micro Kernel Architecture. [Online] http://www.cs.utah.edu/flux/fluke/html/index.html.
  20. Linux Extended Attributes and ACLs. [Online] http://acl.bestbits.at/.
  21. schaufler, Casey. Smack White paper. [Online] http://www.schaufler-ca.com/data/SmackWhitePaper.pdf.
  22. Tomoyo Linux Wiki. TOMOYO Linux : Behavior oriented system analyzer and protector. [Online] http://tomoyo.sourceforge.jp/wiki-e/.
  23. Documentation. The TrustedBSD Project. [Online] http://www.trustedbsd.org/docs.html.
  24. SE-BSD. The TrustedBSD Project. [Online] http://www.trustedbsd.org/sebsd.html.
  25. SE-Darwin. Security Enhanced Darwin. [Online] http://sedarwin.org/.
  26. Trusted Solaris Operating Environment – Documentation. Trusted Solaris Operating System. [Online] http://www.sun.com/software/solaris/trustedsolaris/documentation/index.xml.
  27. Project FMAC: Flexible Mandaroy Access COntrol. [Online] http://hub.opensolaris.org/bin/view/Project+fmac/.
  28. Datasheet. Montavista – Mobilinux. [Online] http://www.mvista.com/download/MontaVista-Mobilinux-5-datasheet.pdf.
  29. Openmoko-Selinux. GSoC. [Online] http://code.google.com/openmoko-selinux/.
  30. Mobile. Trusted Computing Group. [Online] http://www.trustedcomputinggroup.org/developers/mobile.
  31. A trusted mobile phone reference architecturevia secure kernel. Zhang, X. and Ac{\i}i{\c{c}}mez, O. and Seifert, J.P. s.l. : Proceedings of the 2007 ACM workshop on Scalable trusted computing, 2007.
  32. Building Efficient Integrity Measurement and Attestation for Mobile Phone Platforms. Zhang, X. and Ac{\i}i{\c{c}}mez, O. and Seifert, J.P. s.l. : Security and Privacy in Mobile Information and Communication Systems: First International ICST Conference, MobiSec 2009, Turin, Italy, June 3-5, 2009, Revised Selected Papers.
  33. PRIMA: policy-reduced integrity measurement architecture. Jaeger, T. and Sailer, R. and Shankar, U. s.l. : Proceedings of the eleventh ACM symposium on Access control models and technologies, 2006.
  34. Mandatory Access Control for Mobile Devices. Ekberg, Elena Reshetova and Jan-Erik. s.l. : Nokia Research Center Helsinki. NRC-TR-2008-010.

Leave a Reply


(Required)

(Required)