DOCSLIB.ORG

Access Control and Operating System

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Access Control and Operating System Outline (may not finish in one lecture) Access Control and Operating Access Control Concepts Secure OS System Security • Matrix, ACL, Capabilities • Methods for resisting • Multi-level security (MLS) stronger attacks OS Mechanisms Assurance • Multics • Orange Book, TCSEC John Mitchell – Ring structure • Common Criteria • Amoeba • Windows 2000 – Distributed, capabilities certification • Unix Some Limitations – File system, Setuid • Information flow • Windows • Covert channels – File system, Tokens, EFS • SE Linux – Role-based, Domain type enforcement Access control Access control matrix [Lampson] Common Assumption Objects • System knows who the user is File 1 File 2 File 3 … File n – User has entered a name and password, or other info • Access requests pass through gatekeeper User 1 read write - - read – OS must be designed monitor cannot be bypassed User 2 write write write - - Reference Subjects monitor User 3 - - - read read User process ? Resource … User m read write read write read Decide whether user can apply operation to resource Two implementation concepts Capabilities Access control list (ACL) File 1 File 2 … Operating system concept • “… of the future and always will be …” • Store column of matrix User 1 read write - Examples with the resource User 2 write write - • Dennis and van Horn, MIT PDP-1 Timesharing Capability User 3 - - read • Hydra, StarOS, Intel iAPX 432, Eros, … • User holds a “ticket” for … • Amoeba: distributed, unforgeable tickets each resource User m read write write • Two variations References – store row of matrix with user – unforgeable ticket in user space • Henry Levy, Capability-based Computer Systems http://www.cs.washington.edu/homes/levy/capabook/ Access control lists are widely used, often with groups • Tanenbaum, Amoeba papers Some aspects of capability concept are used in Kerberos, … 1 ACL vs Capabilities ACL vs Capabilities Access control list • Associate list with each object User U Capabilty c,d • Check user/group against list Process P Process P • Relies on authentication: need to know user Capabilities User U Capabilty c • Capability is unforgeable ticket Process Q Process Q – Random bit sequence, or managed by OS – Can be passed from one process to another User U Capabilty c • Reference monitor checks ticket Process R Process R – Does not need to know identify of user/process ACL vs Capabilities Roles (also called Groups) Delegation Role = set of users • Cap: Process can pass capability at run time • Administrator, PowerUser, User, Guest • ACL: ???? • Assign permissions to roles; each user gets permission Revocation Role hierarchy • ACL: Remove user or group from list • Partial order of roles Administrator • Cap: Try to get capability back from process? • Each role gets PowerUser – Possible in some systems if appropriate bookkeeping permissions of roles below • OS knows what data is capability • List only new permissions User • If capability is used for multiple resources, have to given to each role revoke all or none … Guest • Other details … Groups for resources, rights Multi-Level Security (MLS) Concepts Permission = 〈right, resource〉 Military security policy Permission hierarchies – Classification involves sensitivity levels, compartments – Do not let classified information leak to unclassified files • If user has right r, and r>s, then user has right s • If user has read access to directory, user has read Group individuals and resources access to every file in directory • Use some form of hierarchy to organize policy Other policy concepts Big problem in access control • Separation of duty • Complex mechanisms require complex input • “Chinese Wall” Policy • Difficult to configure and maintain • Roles, other organizing ideas try to simplify problem 2 Military security policy Military security policy Sensitivity levels Compartments Classification of personnel and data • Class = 〈rank, compartment〉 Satellite data Dominance relation Afghanistan • D D iff rank rank Middle East 1 ≤ 2 1 ≤ 2 Israel and compartment1 ⊆ compartment2 Top Secret Secret • Example: 〈Restricted, Israel〉≤〈Secret, Middle East〉 Confidential Applies to Restricted • Subjects – users or processes Unclassified • Objects – documents or resources Commercial version Bell-LaPadula Confidentiality Model Product specifications When is it OK to release information? Discontinued Two Properties (with silly names) In production • Simple security property OEM – A subject S may read object O only if C(O) ≤ C(S) Internal • *-Property Proprietary – A subject S with read access to O may write object P only if C(O) ≤ C(P) Public In words, • You may only read below your classification and only write above your classification Picture: Confidentiality Biba Integrity Model Read below, write above Read above, write below Rules that preserve integrity of information Two Properties (with silly names) • Simple integrity property Proprietary Proprietary – A subject S may write object O only if C(S) ≥ C(O) (Only trust S to modify O if S has higher rank …) • *-Property S S – A subject S with read access to O may write object P only if C(O) ≥ C(P) (Only move info from O to P if O is more trusted than P) Public Public In words, • You may only write below your classification and only read above your classification 3 Picture: Integrity Problem: Models are contradictory Read above, write below Read below, write above Bell-LaPadula Confidentiality • Read down, write up Biba Integrity Proprietary Proprietary • Read up, write down Want both confidentiality and integrity S S • May use Bell-LaPadula for some classification of personnel and data, Biba for another – Otherwise, only way to satisfy both models is only allow read and write at same classification Public Public In reality: Bell-LaPadula used more than Biba model Example: Common Criteria Other policy concepts Example OS Mechanisms Separation of duty Multics • If amount is over $10,000, check is only valid if Amoeba signed by two authorized people Unix • Two people must be different • Policy involves role membership and ≠ Windows Chinese Wall Policy SE Linux (briefly) • Lawyers L1, L2 in Firm F are experts in banking • If bank B1 sues bank B2, – L1 and L2 can each work for either B1 or B2 – No lawyer can work for opposite sides in any case • Permission depends on use of other permissions These policies cannot be represented using access matrix Multics Multics time period Operating System Timesharing was new concept F.J. Corbato • Designed 1964-1967 • Serve Boston area with one 386-based PC – MIT Project MAC, Bell Labs, GE • At peak, ~100 Multics sites • Last system, Canadian Department of Defense, Nova Scotia, shut down October, 2000 Extensive Security Mechanisms • Influenced many subsequent systems http://www.multicians.org/security.html E.I. Organick, The Multics System: An Examination of Its Structure, MIT Press, 1972 4 Multics Innovations Multics Access Model Segmented, Virtual memory Ring structure • Hardware translates virtual address to real address • A ring is a domain in which a process executes High-level language implementation • Numbered 0, 1, 2, … ; Kernel is ring 0 • Written in PL/1, only small part in assembly lang • Graduated privileges Shared memory multiprocessor – Processes at ring i have privileges of every ring j > i • Multiple CPUs share same physical memory Segments • Each data area or procedure is called a segment Relational database • Segment protection 〈b1, b2, b3〉 with b1 ≤ b2 ≤ b3 • Multics Relational Data Store (MRDS) in 1978 – Process/data can be accessed from rings b1 … b2 Security – A process from rings b2 … b3 can only call segment at • Designed to be secure from the beginning restricted entry points • First B2 security rating (1980s), only one for years Multics process Amoeba Server port Obj # Rights Check field Multiple segments Distributed system • Segments are dynamically linked • Multiple processors, connected by network • Linking process uses file system to find segment • Process on A can start a new process on B • A segment may be shared by several processes • Location of processes designed to be transparent Multiple rings • Procedure, data segments each in specific ring Capability-based system • Access depends on two mechanisms • Each object resides on server – Per-Segment Access Control • Invoke operation through message to server • File author specifies the users that have access to it – Send message with capability and parameters – Concentric Rings of Protection • Call or read/write segments in outer rings – Sever uses object # to indentify object • To access inner ring, go through a “gatekeeper” – Sever checks rights field to see if operation is allowed Interprocess communication through “channels” – Check field prevents processes from forging capabilities Capabilities Server port Obj # Rights Check field Unix file security Owner capability Each file has owner and group • When server creates object, returns owner cap. Permissions set by owner setid – All rights bits are set to 1 (= allow operation) • Read, write, execute – Check field contains 48-bit rand number stored by server - rwxrwx rwx Derived capability • Owner, group, other ownr grp othr • Owner can set some rights bits to 0 • Represented by vector of • Calculate new check field four octal values – XOR rights field with random number from check field Only owner, root can change permissions – Apply one-way function to calculate new check field • This privilege cannot be delegated or shared • Server can verify rights and check filed – Without owner capability, cannot forge derived
Load more

Recommended publications
  • Role Based Access Control on MLS Systems Without Kernel Changes
    Role Based Access Control on For example, roles in a bank may include the role of teller or accountant. Each of these roles has a set of MLS Systems without Kernel privileges or transactions that they can p erform, includ- Changes ing some privileges that are available to b oth roles. Roles can b e hierarchical. For example, some roles in a hospital D. Richard Kuhn may b e health care provider, nurse, and do ctor. The do c- National Institute of Standards and Technology tor role may include all privileges available to the nurse Gaithersburg, Maryland 20899 role, which in turn includes all the privileges available to the health care provider role. Roles have b een used in a variety of forms for com- Abstract puter system security for at least 20 years, and several prop osals for incorp orating roles into existing access con- Role based access control (RBAC) is attracting increas- trol mechanisms have b een published [2], [3], [4]. More ing attention as a security mechanism for b oth commer- recently, formal defnitions for general-purp ose RBAC no- cial and many military systems. This pap er shows how tions have b een prop osed [5], [6], [7]. RBAC can b e implemented using the mechanisms avail- This pap er shows how RBAC can b e implemented able on traditional multi-level security systems that im- using the controls available on traditional lattice-based plement information fow p olicies. The construction from multi-level secure systems. This approach presents a MLS to RBAC systems is signifcant b ecause it shows that number of advantages: the enormous investment in MLS systems can b e lever- aged to pro duce RBAC systems.
    [Show full text]
  • File Permissions Do Not Restrict Root
    Filesystem Security 1 General Principles • Files and folders are managed • A file handle provides an by the operating system opaque identifier for a • Applications, including shells, file/folder access files through an API • File operations • Access control entry (ACE) – Open file: returns file handle – Allow/deny a certain type of – Read/write/execute file access to a file/folder by – Close file: invalidates file user/group handle • Access control list (ACL) • Hierarchical file organization – Collection of ACEs for a – Tree (Windows) file/folder – DAG (Linux) 2 Discretionary Access Control (DAC) • Users can protect what they own – The owner may grant access to others – The owner may define the type of access (read/write/execute) given to others • DAC is the standard model used in operating systems • Mandatory Access Control (MAC) – Alternative model not covered in this lecture – Multiple levels of security for users and documents – Read down and write up principles 3 Closed vs. Open Policy Closed policy Open Policy – Also called “default secure” • Deny Tom read access to “foo” • Give Tom read access to “foo” • Deny Bob r/w access to “bar” • Give Bob r/w access to “bar • Tom: I would like to read “foo” • Tom: I would like to read “foo” – Access denied – Access allowed • Tom: I would like to read “bar” • Tom: I would like to read “bar” – Access allowed – Access denied 4 Closed Policy with Negative Authorizations and Deny Priority • Give Tom r/w access to “bar” • Deny Tom write access to “bar” • Tom: I would like to read “bar” – Access
    [Show full text]
  • Research Purpose Operating Systems – a Wide Survey
    GESJ: Computer Science and Telecommunications 2010|No.3(26) ISSN 1512-1232 RESEARCH PURPOSE OPERATING SYSTEMS – A WIDE SURVEY Pinaki Chakraborty School of Computer and Systems Sciences, Jawaharlal Nehru University, New Delhi – 110067, India. E-mail: [email protected] Abstract Operating systems constitute a class of vital software. A plethora of operating systems, of different types and developed by different manufacturers over the years, are available now. This paper concentrates on research purpose operating systems because many of them have high technological significance and they have been vividly documented in the research literature. Thirty-four academic and research purpose operating systems have been briefly reviewed in this paper. It was observed that the microkernel based architecture is being used widely to design research purpose operating systems. It was also noticed that object oriented operating systems are emerging as a promising option. Hence, the paper concludes by suggesting a study of the scope of microkernel based object oriented operating systems. Keywords: Operating system, research purpose operating system, object oriented operating system, microkernel 1. Introduction An operating system is a software that manages all the resources of a computer, both hardware and software, and provides an environment in which a user can execute programs in a convenient and efficient manner [1]. However, the principles and concepts used in the operating systems were not standardized in a day. In fact, operating systems have been evolving through the years [2]. There were no operating systems in the early computers. In those systems, every program required full hardware specification to execute correctly and perform each trivial task, and its own drivers for peripheral devices like card readers and line printers.
    [Show full text]
  • Making Linux Security Frameworks Available to Containers
    Security Namespace : Making Linux Security Frameworks Available to Containers Yuqiong Sun, David Safford, Mimi Zohar, Dimitrios Pendarakis, Zhongshu Gu and Trent Jaeger Container vs. Virtual Machines • Containers are operating system level virtualization environment for running multiple isolated Linux systems on a single Linux control host Image credit: Docker Inc. and RightScale Inc. Is Kernel Sharing All Good? • Container owners cannot leverage kernel security frameworks to protect their containers • I.e., cannot apply local security policies to govern integrity measurement, code execution, mandatory access control, etc. Integrity Attestation for Container • On a container cloud, can a container owner attest integrity of his/her containers to his/her customers? • Exactly what Linux Integrity subsystem (a.k.a. IMA) is designed for kernel mmap() extend Process Measure record Policy Measurements Integrity Attestation for Container (Cont.) • But… • Mixed measurements from different containers and host Process mmap() kernel extend Container1 Measure mmap() record Process Policy Measurements Container2 Integrity Attestation for Container (Cont.) • But… • Mixed measurements from different containers and host • Different versions of policies Process mmap() kernel extend Container1 Measure mmap() record Process Policy1 Policy2 Measurements Container2 Integrity Attestation for Container (Cont.) • But… • Mixed measurements from different containers and host • Different versions of policies • And policies do not always agree with each other Me:
    [Show full text]
  • Operating Systems & Virtualisation Security Knowledge Area
    Operating Systems & Virtualisation Security Knowledge Area Issue 1.0 Herbert Bos Vrije Universiteit Amsterdam EDITOR Andrew Martin Oxford University REVIEWERS Chris Dalton Hewlett Packard David Lie University of Toronto Gernot Heiser University of New South Wales Mathias Payer École Polytechnique Fédérale de Lausanne The Cyber Security Body Of Knowledge www.cybok.org COPYRIGHT © Crown Copyright, The National Cyber Security Centre 2019. This information is licensed under the Open Government Licence v3.0. To view this licence, visit: http://www.nationalarchives.gov.uk/doc/open-government-licence/ When you use this information under the Open Government Licence, you should include the following attribution: CyBOK © Crown Copyright, The National Cyber Security Centre 2018, li- censed under the Open Government Licence: http://www.nationalarchives.gov.uk/doc/open- government-licence/. The CyBOK project would like to understand how the CyBOK is being used and its uptake. The project would like organisations using, or intending to use, CyBOK for the purposes of education, training, course development, professional development etc. to contact it at con- [email protected] to let the project know how they are using CyBOK. Issue 1.0 is a stable public release of the Operating Systems & Virtualisation Security Knowl- edge Area. However, it should be noted that a fully-collated CyBOK document which includes all of the Knowledge Areas is anticipated to be released by the end of July 2019. This will likely include updated page layout and formatting of the individual Knowledge Areas KA Operating Systems & Virtualisation Security j October 2019 Page 1 The Cyber Security Body Of Knowledge www.cybok.org INTRODUCTION In this Knowledge Area, we introduce the principles, primitives and practices for ensuring se- curity at the operating system and hypervisor levels.
    [Show full text]
  • Mixed-Criticality Scheduling and Resource Sharing for High-Assurance Operating Systems
    Mixed-Criticality Scheduling and Resource Sharing for High-Assurance Operating Systems Anna Lyons Submitted in fulfilment of the requirements for the degree of Doctor of Philosophy School of Computer Science and Engineering University of New South Wales Sydney, Australia September 2018 Abstract Criticality of a software system refers to the severity of the impact of a failure. In a high-criticality system, failure risks significant loss of life or damage to the environ- ment. In a low-criticality system, failure may risk a downgrade in user-experience. As criticality of a software system increases, so too does the cost and time to develop that software: raising the criticality also raises the assurance level, with the highest levels requiring extensive, expensive, independent certification. For modern cyber-physical systems, including autonomous aircraft and other vehicles, the traditional approach of isolating systems of different criticality by using completely separate physical hardware, is no longer practical, being both restrictive and inefficient. The result is mixed-criticality systems, where software applications with different criticalities execute on the same hardware. Sufficient mechanisms are required to ascertain that software in mixed-criticality systems is sufficiently isolated, otherwise, all software on that hardware is promoted to the highest criticality level, driving up costs to impractical levels. For mixed-criticality systems to be viable, both spatial and temporal isolation are required. Current aviation standards allow for mixed-criticality systems where temporal and spatial resources are strictly and statically partitioned in time and space, allowing some improvement over fully isolated hardware. However, further improvements are not only possible, but required for future innovation in cyber-physical systems.
    [Show full text]
  • Discretionary Access Control (DAC)
    CS 5323 Discretionary Access Control (DAC) Prof. Ravi Sandhu Executive Director and Endowed Chair Lecture 7 [email protected] www.profsandhu.com © Ravi Sandhu World-Leading Research with Real-World Impact! 1 Authentication, Authorization, Audit AAA Authentication Authorization Audit Who are You? What are You What Did You Do? Allowed to Do? siloed integrated © Ravi Sandhu World-Leading Research with Real-World Impact! 2 Access Control Fixed policy Discretionary Access Control Mandatory Access Control (DAC), 1970 (MAC), 1970 Role Based Access Control (RBAC), 1995 Attribute Based Access Control (ABAC), ???? Flexible policy © Ravi Sandhu World-Leading Research with Real-World Impact! 3 Access Matrix Model © Ravi Sandhu World-Leading Research with Real-World Impact! 4 Access Matrix Model Objects (and Subjects) F G S U r w r u own b j r w e V c own t s rights © Ravi Sandhu World-Leading Research with Real-World Impact! 5 Access Matrix Model Basic Abstractions Subjects Objects Rights The rights in a cell specify the access of the subject (row) to the object (column) © Ravi Sandhu World-Leading Research with Real-World Impact! 6 Users and Subjects A subject is a program (application) executing on behalf of a user A user may at any time be idle, or have one or more subjects executing on its behalf User-subject distinction is important if subject’s rights are different from a user’s rights Usually a subset In many systems a subject has all the rights of a user A human user may manifest as multiple users (accounts, principals) in the system © Ravi Sandhu World-Leading Research with Real-World Impact! 7 Users and Subjects JOE.TOP-SECRET JOE.SECRET JOE JOE.CONFIDENTIAL JOE.UNCLASSIFIED USER SUBJECTS © Ravi Sandhu World-Leading Research with Real-World Impact! 8 Users and Subjects JANE.CHAIRPERSON JANE.FACULTY JANE JANE.
    [Show full text]
  • Role Hierarchies and Constraints for Lattice-Based Access Controls
    Role Hierarchies and Constraints for Lattice-Based Access Controls Ravi Sandhu* George Mason University & SETA Corporation~* Abstract Role-based access control (RBAC) is a promising alternative to traditional discretionary and mandatory access controls. In RBAC permis- sions are associated with roles, and users are made members of appropriate roles thereby acquiring the roles' permissions. In this paper we formally show that lattice-based mandatory access controls can be enforced by appropriate configuration of RBAC components. Our constructions demonstrate that role hierarchies and constraints are required to effectively achieve this result. We show that variations of the lattice-based *-property, such as write-up (liberal *-property) and no-write-up (strict ,-property), can be easily accommodated in RBAC. Our results attest to the flexibility of RBAC and its ability to ac- commodate different policies by suitable configuration of role hierarchies and constraints. 1 INTRODUCTION Role-based access control (RBAC) has recently received considerable attention as a promising alternative to traditional discretionary and mandatory access controls (see, for example, [FK92, SCY96, SCFY96]). In RBAC permissions are associated with roles, and users are made members of appropriate roles thereby acquiring the roles' permissions. This greatly simplifies management of permissions. Roles are created for the various job functions in an organization and users are assigned roles based on their responsibilities and qualifications. Users can be easily reassigned from one role to another. Roles can be granted new permissions as new applications and systems are incorporated, and permissions can be revoked from roles as needed. An important characteristic of RBAC is that by itself it is policy neutral.
    [Show full text]
  • Operating System Verification—An Overview
    Sadhan¯ a¯ Vol. 34, Part 1, February 2009, pp. 27–69. © Printed in India Operating system verification—An overview GERWIN KLEIN Sydney Research Laboratory, NICTA,∗ Australia, School of Computer Science and Engineering, University of New South Wales, Sydney, Australia e-mail: [email protected] Abstract. This paper gives a high-level introduction to the topic of formal, interactive, machine-checked software verification in general, and the verification of operating systems code in particular. We survey the state of the art, the advantages and limitations of machine-checked code proofs, and describe two specific ongoing larger-scale verification projects in more detail. Keywords. Formal software verification; operating systems; theorem proving. 1. Introduction The fastest, cheapest and easiest way to build something is properly the first time (Parker 2007). This engineer’s credo has made it into popular literature, but it seems to be largely ignored in the world of software development. In the late 1960s a software crisis was diagnosed on a summit in the Bavarian Alps (Naur & Randell 1969): Software was getting more and more complex, and we had no structured way of building it. We ended up with projects that took significantly longer than planned, were more expensive than planned, delivered results that did not fully address customer needs, or at worst were useless. This summit in the late 1960s is widely seen as the birth of the discipline of software engineering. Now, almost 40 years later, we have come a long way. There are numerous books on software engineering, a plenitude of methodologies, programming languages, and processes to choose from.
    [Show full text]
  • Scalability of Microkernel-Based Systems
    Scalability of Microkernel-Based Systems Zur Erlangung des akademischen Grades eines DOKTORS DER INGENIERWISSENSCHAFTEN von der Fakultat¨ fur¨ Informatik der Universitat¨ Fridericiana zu Karlsruhe (TH) genehmigte DISSERTATION von Volkmar Uhlig aus Dresden Tag der mundlichen¨ Prufung:¨ 30.05.2005 Hauptreferent: Prof. Dr. rer. nat. Gerhard Goos Universitat¨ Fridericiana zu Karlsruhe (TH) Korreferent: Prof. Dr. sc. tech. (ETH) Gernot Heiser University of New South Wales, Sydney, Australia Karlsruhe: 15.06.2005 i Abstract Microkernel-based systems divide the operating system functionality into individ- ual and isolated components. The system components are subject to application- class protection and isolation. This structuring method has a number of benefits, such as fault isolation between system components, safe extensibility, co-existence of different policies, and isolation between mutually distrusting components. How- ever, such strict isolation limits the information flow between subsystems including information that is essential for performance and scalability in multiprocessor sys- tems. Semantically richer kernel abstractions scale at the cost of generality and mini- mality–two desired properties of a microkernel. I propose an architecture that al- lows for dynamic adjustment of scalability-relevant parameters in a general, flex- ible, and safe manner. I introduce isolation boundaries for microkernel resources and the system processors. The boundaries are controlled at user-level. Operating system components and applications can transform their semantic information into three basic parameters relevant for scalability: the involved processors (depending on their relation and interconnect), degree of concurrency, and groups of resources. I developed a set of mechanisms that allow a kernel to: 1. efficiently track processors on a per-resource basis with support for very large number of processors, 2.
    [Show full text]
  • The Simplified Mandatory Access Control Kernel
    The Simplified Mandatory Access Control Kernel Casey Schaufler [email protected] Mandatory Access Control Computer systems employ a variety of schemes to constrain how information is shared among the people and services using the machine. Some of these schemes allow the program or user to decide what other programs or users are allowed access to pieces of data. These schemes are called discretionary access control mechanisms because the access control is specified at the discretion of the user. Other schemes do not leave the decision regarding what a user or program can access up to users or programs. These schemes are called mandatory access control mechanisms because you don’t have a choice regarding the users or programs that have access to pieces of data. Bell & LaPadula From the middle of the 1980’s until the turn of the century Mandatory Access Control (MAC) was very closely associated with the Bell & LaPadula security model, a mathematical description of the United States Department of Defense policy for marking paper documents. MAC in this form enjoyed a following within the Capital Beltway and Scandinavian supercomputer centers but was often sited as failing to address general needs. Domain Type Enforcement Around the turn of the century Domain Type Enforcement (DTE) became popular. This scheme organizes users, programs, and data into domains that are protected from each other. This scheme has been widely deployed as a component of popular Linux distributions. The administrative overhead required to maintain this scheme and the detailed understanding of the whole system necessary to provide a secure domain mapping leads to the scheme being disabled or used in limited ways in the majority of cases.
    [Show full text]
  • Controlled Environment to Run Untrusted Applications
    CONTROLLED ENVIRONMENT TO RUN UNTRUSTED APPLICATIONS A thesis submitted To Kent State University in partial Fulfillment of the requirements for the Degree of Master of Science by TAHANI ALBALAWI August, 2013 Thesis written by TAHANI ALBALAWI B.S., Taiba University, KSA 2007 M.S., Kent State University, USA, 2013 Approved by Michael Rothstein, Advisor Javed Khan , Chair, Department of Computer Science Raymond Craig, Dean, College of Arts and Sciences ii Abstract Untrusted applications pose a security threat to systems they run on. At the same time sometimes a user wants to run such applications without risking unauthorized access to certain parts of the system. For this reason we propose a controlled environment to run host untrusted applications based on AppArmor tool. We intend to augment the usefulness of AppArmor by further restricting the permissions of the files accessible to the process using other system mechanisms, such as NFS and Chroot. Based on the principle of least authority, programs can run in a restricted secure environment limiting access to a subset of the files. This way untrusted applications are allowed to run with limits to protect the system. iii Table of Contents LIST OF FIGURES ..................................................................................................... vii LIST OF TABLES ...................................................................................................... vii DEDICATION.............................................................................................................
    [Show full text]