Security Analysis of the New Microsoft MAC Solution Abstract 1 Mandatory
Total Page:16
File Type:pdf, Size:1020Kb
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. -
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 -
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 -
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: -
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. -
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. -
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. -
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. -
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............................................................................................................. -
Local Security and Permissions
Ondřej Ševeček | GOPAS a.s. | MCM: Directory Services | MVP: Enterprise Security | [email protected] | www.sevecek.com | LOCAL SECURITY AND PERMISSIONS Outline . Generic Terminology . NTFS Permissions . Registry Permissions . LDAP Permissions . File Sharing . Disk Quotas . Windows Management Instrumentation . Other Permission Settings . Windows Firewall . Service Accounts and Impersonation . Physical Security . BitLocker . Dynamic Access Control Advanced Windows Security GENERIC TERMINOLOGY Security Descriptor . Objects are protected with permissions files, folders, registry keys, LDAP objects, printers, windows, desktops, ... ACE – Access Control Entry one item in the permissions list Deny, Allow . ACL – Access Control List permission list . SACL – System Access Control List auditing ACL . Owner Object Owner . Members of Administrators group owner is Administrators group instead of the user . Can always change permissions even if explicitly denied . Take Ownership user right that allows taking ownership . CREATOR OWNER identity used as a placeholder to express the current owner of the file ACL Processing vs. ACE Order . ACEs are ordered Note: it is contrary to a common statement that Deny ACEs are always stronger the correct order must be maintained by applications when they modify ACL . ACEs are evaluated in the order present like with firewall rules Lab: Investigate Incorrect ACE Order . Log on to GPS-WKS as Kamil . Start REGEDIT . Right-click on SYSTEM/CurrentControlSet/Services/{anyGUID}/ Parametes/Tcpip and select Permissions . Note the text: The permissions on the object are incorrectly ordered, which may cause some entries to be ineffective . Click Cancel to see the incorrect order, click Advanced note that the Full Control permissions are lower than expected Auditing . Object Access auditing category general switch to turn auditing on/off . -
A Survey of Access Control Policies
A Survey of Access Control Policies Amanda Crowell University of Maryland [email protected] ABSTRACT nisms to the standard checks. Modern operating systems each have different implementa- tions of access controls and use different policies for deter- The Common Weakness Enumeration (CWE) describes sev- mining the access that subjects may have on objects. This eral mistakes that application developers have made in re- paper reviews the three main types of access control policies: gard to access control. Often, developers do not give the discretionary, mandatory, and role-based. It then describes application objects the appropriate rights to begin with (i.e. how Windows and various Unix systems implement their they specify more rights than are necessary) and do not chosen access control policies. Finally, it discusses some modify rights throughout the application's lifetime. Since common mistakes that application programmers make when spawned processes typically take on the rights of the spawn- enforcing access control in their applications and gives some ing process, rights might be passed on to the spawned pro- general guidance to reduce the occurrence of mistakes. cess that were unintentional. In response to these mistakes, some researchers have developed guidelines for using access 1. INTRODUCTION controls appropriately. These include: (a) understanding Modern operating systems use different mechanisms for pro- what information is available to the system and how it can viding access control. These mechanisms are designed to be used to make decisions, (b) determining exactly which meet security policies that vary in the way access decisions rights are absolutely necessary and only allow those and are made. -
[MS-DTYP-Diff]: Windows Data Types
[MS-DTYP-Diff]: Windows Data Types Intellectual Property Rights Notice for Open Specifications Documentation ▪ Technical Documentation. Microsoft publishes Open Specifications documentation (“this documentation”) for protocols, file formats, data portability, computer languages, and standards support. Additionally, overview documents cover inter-protocol relationships and interactions. ▪ Copyrights. This documentation is covered by Microsoft copyrights. Regardless of any other terms that are contained in the terms of use for the Microsoft website that hosts this documentation, you can make copies of it in order to develop implementations of the technologies that are described in this documentation and can distribute portions of it in your implementations that use these technologies or in your documentation as necessary to properly document the implementation. You can also distribute in your implementation, with or without modification, any schemas, IDLs, or code samples that are included in the documentation. This permission also applies to any documents that are referenced in the Open Specifications documentation. ▪ No Trade Secrets. Microsoft does not claim any trade secret rights in this documentation. ▪ Patents. Microsoft has patents that might cover your implementations of the technologies described in the Open Specifications documentation. Neither this notice nor Microsoft's delivery of this documentation grants any licenses under those patents or any other Microsoft patents. However, a given Open Specifications document might be covered by the Microsoft Open Specifications Promise or the Microsoft Community Promise. If you would prefer a written license, or if the technologies described in this documentation are not covered by the Open Specifications Promise or Community Promise, as applicable, patent licenses are available by contacting [email protected].