The article entitled “Setuid Demystified” tried to demystify the inner workings of the uid-setting system calls, which are inherent and commonly used on Unix-based operating systems.
The first paper, as its name implies, tried to unravel the way uid-setting systems calls in Unix-based operating systems work. What are these uid-system calls anyway? Well, it’s a sort of an API which one could use/call in Unix-based systems to set or to drop, temporarily or permanently, the privileges i.e. resources, a program can access. For example, when you want a program to run with root privileges, then you’ll probably call one of the functions within this API.
One of the key issues that the researches tried to address on their study is the inconsistencies of the behaviour of these system calls on several Unix-based operating systems. The researchers attributed this to the “ambiguous” or lack thereof, of a specification documenting what these system calls do and how should they do it i.e. the rules or invariants that concern each function. This could possibly lead to some serious security and portability issues on applications developed for such systems as described in the article.
On their study, the researches first tried to determine the behaviour of these system calls across several implementations by examining their actual source files. After trying such approach, they eventually realized the impracticality of what they’re doing, and then they decided to build a more formal methodology. They have implemented a Finite State Automaton (FSA) that covers the different possible states of a particular process altered by the uid-system calls made within it [1]. They tried to automate the process of building such FSA model for each uid-system calls through simulation. Their simulator allowed them to create FSA models faster and less tedious. This in turn enabled them to easily compare the differences of the different FSA model generated from each uid-system call implementation. This lead to a much faster detection of the inconsistencies present in several implementations of each uid-system calls. Moreover, their formal method makes the automation of such detection mechanism possible. The formal method also led to the discovery of some security vulnerabilities in some implementation of the uid-system calls.
The one thing that caught my interest in this paper is the way by which the researchers developed a formal method for an activity that is rather tedious if done manually. Of course they being successful in their study clearly intensifies the possibility of developing formal models for things that may appear so complex at times. Development of such formal methods also enables a deeper understanding of what’s happening “inside” albeit some necessary abstractions are employed.
The other article, “Understanding Android Security”, discussed the core security mechanisms employ on Android, a mobile operating system.
They discussed the mechanism by which Android manage the privileges of the different application running in it. The security framework employed by Android developers follows a permission labeling scheme. An Android developer assigns permission labels to his application by explicitly specifying them on an XML manifest file [2]. These permission labels specify how this particular application handles accesses made by other application to its components. This manifest file is use to set an application’s permission labels during installation and stays permanent until a new installation is made.
Although such security framework is inherent on the Android platform, programming errors made by security-unaware developers are still the major concerns which influenced the existence of security vulnerabilities on Android applications. In this regard, the researchers developed a tool, called Kirin, which automates the verification of consistency of the set of permissions defined in an application.
Automation seems everything, isn’t it?
References:
[1] H. Chen, D. Wagner, and D. Dean. “Setuid Demystified”.
[2] W. Enck, M. Ongtang, and P. McDaniel, “Understanding Android Security”. IEEE Security and Privacy. 2009, pp. 50-57
No comments:
Post a Comment