Toward least-privilege isolation for software

Hackers leverage software vulnerabilities to disclose, tamper with, or destroy sensitive data. To protect sensitive data, programmers can adhere to the principle of least-privilege, which entails giving software the minimal privilege it needs to operate, which ensures that sensitive data is only available to software components on a strictly need-to-know basis. Unfortunately, applying this principle in practice is dif- �cult, as current operating systems tend to provide coarse-grained mechanisms for limiting privilege. Thus, most applications today run with greater-than-necessary privileges. We propose sthreads, a set of operating system primitives that allows �ne-grained isolation of software to approximate the least-privilege ideal. sthreads enforce a default-deny model, where software components have no privileges by default, so all privileges must be explicitly granted by the programmer. Experience introducing sthreads into previously monolithic applications|thus, partitioning them|reveals that enumerating privileges for sthreads is di�cult in practice. To ease the introduction of sthreads into existing code, we include Crowbar, a tool that can be used to learn the privileges required by a compartment. We show that only a few changes are necessary to existing code in order to partition applications with sthreads, and that Crowbar can guide the programmer through these changes. We show that applying sthreads to applications successfully narrows the attack surface by reducing the amount of code that can access sensitive data. Finally, we show that applications using sthreads pay only a small performance overhead. We applied sthreads to a range of applications. Most notably, an SSL web server, where we show that sthreads are powerful enough to protect sensitive data even against a strong adversary that can act as a man-in-the-middle in the network, and also exploit most code in the web server; a threat model not addressed to date

Are chrome extensions compliant with the spirit of least privilege?

Extensions are small applications installed by users and enrich the user experience of browsing the Internet. Browsers expose a set of restricted APIs to extensions. To be used, extensions need to list the permissions associated with these APIs in a mandatory extension file named manifest. In particular, Chrome’s permission ecosystem was designed in the spirit of the least privilege. Yet, this paper demonstrates that 39.8% of the analyzed extensions provided by the official Web Store are compliant with the spirit of least privilege. Also, we develop: (1) a browser extension to make aware regular users of the permissions the extensions they install; (2) a web app where extensions developers can check whether their extensions are compliant with the spirit of the least privileged; and (3) a set of scripts that can be part of the vendors’ acceptance criteria such that when developers upload their extensions to the official repositories, the scripts automatically analyze the extensions and generate a report about the permissions and the usage

A DYNAMIC ROLE SWITCHING APPROACH TO ENFORCE PRINCIPLE OF LEAST PRIVILEGE

This document issues a method to consider adding a proxy module that can be dynamically switched to different granted roles in order to decouple different business functional requests and to be executed under the least permissions. This document designs this module as an independent component in the example system architecture, but this disclosure will not be limited by this architecture design

State of Utah v. Jindall : Brief of Appellant

Security principles, like least privilege, are among the resources in the security body of knowledge that survived the test of time. The implementation of these principles in a software architecture is difficult, as there are no systematic rules on how to apply them in practice. As a result, they are often neglected, which lowers the overall security level of the software system and increases the cost necessary to fix this later in de development life-cycle. This report improves the support for least privilege in software architectures by (i) defining the foundations to identify potential violations of the principle herein and (ii) elicitating architectural transformations that positively impact the security properties of the architecture, while preserving the semantics thereof. These results have been implemented and validated in a number of case studies.nrpages: 74status: publishe

Least-Privilege Identity-Based Policies for Lambda Functions in Amazon Web Services (AWS)

We address least-privilege in a particular context of public cloud computing: identity-based policies for callback functions, called Lambda functions, in serverless applications of the Amazon Web Services (AWS) cloud provider. We argue that this is an important context in which to consider the fundamental security design principle of least-privilege, which states that every thread of execution should possess only those privileges it needs. We observe that poor documentation from AWS makes the task of devising least-privilege policies difficult for developers of such applications. We then describe our experimental approach to discovering least-privilege for a method call, and our observations, some of which are alarming, from running it against 171 methods across five different AWS services. We discuss also our assessment of two repositories, and two full-fledged serverless applications, all of which are publicly available, for least-privilege, and find that the vast majority of policies are over-privileged. We conclude with a few recommendations for developers of Lambda functions in AWS. Our work suggests that much work is needed, both from developers and providers, in securing cloud applications from the standpoint of least-privilege

Repairing Inconsistent XML Write-Access Control Policies

XML access control policies involving updates may contain security flaws, here called inconsistencies, in which a forbidden operation may be simulated by performing a sequence of allowed operations. This paper investigates the problem of deciding whether a policy is consistent, and if not, how its inconsistencies can be repaired. We consider policies expressed in terms of annotated DTDs defining which operations are allowed or denied for the XML trees that are instances of the DTD. We show that consistency is decidable in PTIME for such policies and that consistent partial policies can be extended to unique "least-privilege" consistent total policies. We also consider repair problems based on deleting privileges to restore consistency, show that finding minimal repairs is NP-complete, and give heuristics for finding repairs.Comment: 25 pages. To appear in Proceedings of DBPL 200

Adoption of the Least Privilege Separation Kernel (LPSK) for the Atom Platform, Research Report

The Goal of the work was to port the original LPSK (Least Privilege Separation Kernel) prototype developed by the MYSEA group at NPS as part of the TCX project to PC platforms that have the Intel Atom processor, which is a small low-power integrated circuit that will eventually make its way into small, embedded devices. Because the Intel Atom is x86- based, the effort was focused mainly on getting the LPSK to run on modern PC architecture.Military Wireless Communications (MWC

Політика безпеки інформації в автоматизованій системі

An information security policy addresses many issues such as the following: disclosure, integrity, and availability concerns; who may access what information in what manner; basis on which the access decision is mademaximized sharing versus least privilege; separation of duties; who controls and who owns the information; and authority issues