Operating-system access control allows restricting access to resources based on the identity of the authenticated user executing a program. In modern run-time environments, such as Java and the CLR, programs under execution are obtained by dynamically assembling components. At run time, when different components are dynamically combined to form a program, a component provider could behave as an active attacker (one capable of observing and modifying a part of the system state) and violate the integrity of the system by injecting into the program a component that performs operations that the system administrator did not intend to authorize. As a result, in such systems, there is the need for a code provider to undergo authentication and authorization much the same way as the user who executes the final program. A component can authenticate itself based on its origin in the network and the digital signature applied by the component provider before distribution. The system administrator assigns "permissions" to authenticated components. A permission is the right to access a restricted resource. At run time, when a component attempts, directly or indirectly, to access a restricted resource, the underlying run-time environment demands that the component prove possession of the relevant permission.
A system administrator installing a program must configure its access-control policy by granting or denying permissions to the program components. In the software lifecycle, this challenge is faced also by component developers and providers who publish permission recommendations for their components before distributing them. An overly permissive policy constitutes a violation of the Principle of Least Privilege (PLP), which establishes that a user or program should never be granted more permissions than those it requires to function correctly. If the policy is too restrictive, the program will not function properly due to run-time authorization failures. Source code is not always available, so manual code inspection, besides being complicated, time consuming, tedious and error prone, may not even be an option.
Dynamic analysis is an alternative. With this technique, a component is tested, initially with no permissions. Any attempt by the component to directly or indirectly access a restricted resource will result in a run-time authorization failure. Each failure is logged, the access-control policy is updated by granting the component the missing permissions (assuming that it is safe to do so), and the program is restarted. This process must be iterated until no more authorization failures are found. However, there is no guarantee that the access-control policy obtained at the end of this process will be sufficient to execute the program without failures. Absence of a complete suite of test cases can leave some execution paths undiscovered until deployment, thereby exposing the deployed program to unjustified authorization failures. Furthermore, testing a potentially malicious program can harm the underlying system.
Static analysis has the ability to model all the possible paths of execution of a program without executing it. Thus, a static permission analysis can detect all the permission requirements. Hwever, if the analysis is too conservative, it will compute false positives—permissions that are not actually needed and that, if granted, will result in PLP violations. Hence, minimizing the number of false positives in permission analysis is crucial.
We have designed and implemented a static permission-analysis tool called Automated Authorization Analysis (A3). A3 combines static string analysis with a demand-driven permission-tracking algorithm to reduce the number of false positives. Key insights used in the design of A3 include combining a modular library analysis with a library-client permission analysis. The latter is made more precise by the use of string analysis and program slicing to find security-sensitive program regions and to disambiguate permission-propagation paths in them for acceptable precision at practical cost. String analysis is also used to resolve string values in permission requirements. Using A3 on publicly available benchmarks shows outstanding precision, scalability, and efficiency improvements over the best previously existing analysis, IBM's [a href="http://www.alphaworks.ibm.com/tech/sword4j"]Security Workbench Development Environment for Java (SWORD4J).
Contributors
Emmanuel Geay, Marco Pistoia, Takaaki Tateishi, Barbara G. Ryder and Julian Dolby.
Publications
Patents