I am using Ubuntu 9.10

• Open terminal and write sudo nautilus. Than enter your password. A file browser window will open. Browse to the addons folder in the openerp-server. The path would be something like this e.g, /usr/local/lib/python2.6/dist-packages/openerp-server/addons/
• create a new folder in it and name it “sim”, short for Student Information Management. Open the folder.
• Create the following files in the sim folder.
  1. __init__.py (its “double underscore init double underscore.py”). Python file.
  2. __terp__py (its “double underscore terp double underscore.py”). Python file.
  3. sim.py Python file
  4. sim_view.xml XML file.
• Open __init__.py file and write the following code.
  1. import sim
  2. sim is the name of our module that we are developing and its the name our major python file that will include all our python code. Save the file and exit
• Open __terp__.py file and write the following code.

{

‘name’: ‘Student Information Management’,

‘version’: ‘0.1′,

‘category’: ‘Tools’,

‘description’: “”"This module is for the Student Information Management.”"”,

‘author’: ‘Mir Nauman Tahir’,

‘website’: ‘http://mirnauman.wordpress.com/’,

‘depends’: ['base'],

‘init_xml’: [],

‘update_xml’: [

'sim_view.xml'

],

‘demo_xml’: [],

‘installable’: True,

}

You can write your own strings in “name, description,author and website”Save the file and exit

• Now open sim.py file and write the following code.

class student(osv.osv):

_name = “sim.student”

_description = “This table is for keeping personal data of student”

_columns = {

‘name’: fields.char(‘Registration Number’,size=256,required=True),

’student_name’: fields.char(‘Student Name’,size=256,required=True),

‘father_name’: fields.char(‘Father Name’,size=256),

‘gender’:fields.selection([('male','Male'),('female','Female')],’Gender’),

‘contact_no’:fields.char(‘Contact Number’,size=256)

}

student()

This code will create a table in the database “sim_student”. In database the dot between sim and student is converted to underscore. The value for _description can be any string of your choice. _column is a dictionary and contains all the column names of the table with their data types. In side the parenthesis is the caption for that field that will appear on the form, its size and “required=True” shows that its a must to enter this field. The “field.selection” creates a drop down list control that has two items, Male and Female. The “student()” shows the end of the class.

Some precautions. Python is a language that works with indentation. One space extra or less can generate billions of errors and you wont get a proper clue, if you are not using the proper editor.

• Open the sim_view.xml file and write the following code

<!– ============== Document Start================= –>

<?xml version=”1.0″?>

<openerp>

<data>

<!– ============== student================= –>

<!– 1^st part of the sim_view start–>

<record model=”ir.ui.view” id=”student_form”>

<field name=”name”>Student</field>

<field name=”model”>sim.student</field>

<field name=”type”>form</field>

<field name=”arch” type=”xml”>

<form string=”Student”>

<field name=”name”/>

<field name=”student_name”/>

<field name=”father_name”/>

<field name=”gender”/>

<field name=”contact_no”/>

</form>

</field>

</record>

<!– 1^st part of the sim_view end–>

<!–2^nd part of the sim_view start–>

<record model=”ir.ui.view” id=”student_tree”>

<field name=”name”>Student</field>

<field name=”model”>sim.student</field>

<field name=”type”>tree</field>

<field name=”arch” type=”xml”>

<tree string=”Student”>

<field name=”name”/>

<field name=”student_name”/>

<field name=”father_name”/>

<field name=”gender”/>

<field name=”contact_no”/>

</tree>

</field>

</record>

<!–2^nd part of the sim_view end–>

<!– 3^rd part of the sim_view start–>

<record model=”ir.actions.act_window” id=”action_student”>

<field name=”name”>Student</field>

<field name=”res_model”>sim.student</field>

<field name=”view_type”>form</field>

<field name=”view_mode”>tree,form</field>

</record>

<!–3^rd part of the sim_view end–>

<!–4^th part of the sim_view start–>

<menuitem name=”SIM/Student/StudentInfo” id=”menu_sim_student” action=”action_student”/>

<!–4^th part of the sim_view end–>

</data>

</openerp>

<!– ============== Document End=================–>

From my perspective every view file for an OpenERP module will consist of atleast 3 or 4 parts

1. The form part.
2. The tree part.
3. The action part.
4. The menu part.

And thats how I have divided the above documents in 4 parts. Its not necessary that an OpenERP module must have all the above 4 parts. It can have form,action and menu parts or tree,action and menu or all the four parts. The 1^st part will create a form view. It should be kept in mind that the <field name=”model”>sim.student</field>, the sim.student should be exactly the same as the value for the _name=”sim.student”. This refers to the sim_student table for which we are creating this form. The <field name=”type”>form</field> shows which view type it is, a tree or a form. The next important block is the <field name=”name”/>,<field name=”student_name”/>….. the values for the name here will be the exact column names from our sim.py file. The rest of the things don’t need much explanation for now.

The 2^nd part contain exactly the same things as the form view with very few differences like the type is tree here instead of form. And the column fields are encapsulated in the <tree string=”Student” …..>. This will create a grid type view displaying all the rows and column that are entered. This grid type view is called tree view.

The 3^rd part is the action. In res_model give the exact model name or the table name from our sim.py file, I.e “sim.student”. Specify a view_type that is form and view mode that is tree, form. The action defines when a menu is clicked for this action which form will it open. In the menu, id of this action will be used.

The 4^th part is related to creating the menu. A menu has the following important parts that are name,id,action and in some cases parent. There are two ways for creating a menu. I have used a way that I found more simple. “SIM/Student/StudentInfo”, SIM is the primary menu and appears in the left pane. When SIM is clicked Student menu will appear in the right pane. When student is clicked StudentInfo will appear and when StudentInfo is clicked it will open the form that is defined in the action for this menu.

Save the file, exit. Now run OpenERP client. Install the current developed module and check it in working condition. More complexities to this tutorial will be added soon.

http://imsciences.edu.pk/serg/wp-content/uploads/2010/09/strength-and-weakness-of-each-mechanism.pdf

The deliverable starts with an introduction to Android followed by Openmoko, both of which are open source mobile platforms. Security enforcement mechanism of both platforms are discussed separately. Finally a comparative analysis is done between Android and Openmoko focusing on strengths and weaknesses of their policy enforcement mechanisms.

Evolution of mandatory access control can be traced back to the early efforts Defense Science Board starting in October 1967 to enhance security that would protect classified information exposed to remote access and resource sharing. The task force presented a report named “security controls for computer systems” in February 1970 recommending a number of policy and technical actions to be taken to reduce threat to classified data accessed remotely. The DoD directive 5200.28 was published with a manual to enhance the computer systems of all defense and intelligence agencies. Research and development efforts were undertaken by Airforce, ARPA, and others to develop and demonstrate practical solutions.^[1]

This work progressed to the first evaluation criteria known as Trusted Computing Security Evaluation Criteria, which is described in the next subsection.Earlier MAC implementations were Honeywell’s SCOMP ^[2] and NSA Blacker^[3], concerned with MLS to protect military oriented security classification levels with efficient enforcement.

1.1 Trusted Computer System Evaluation Criteria (TCSEC)

TCSEC ^[1] is a US Government Department of Defense (DoD) standard that sets basic requirements for assessing the effectiveness of computer security controls built into a computer system. The TCSEC was used to evaluate, classify and select computer systems being considered for the processing, storage and retrieval of sensitive or classified information.
Orthogonal to DoD efforts, the National Bureau of Standards (NBS) had begun work to define issues and technical solutions for constructing, evaluating, and auditing trusted computer systems. In this work NBS conducted two workshops on audit and evaluation of security in computer systems. The main deliverable of the second workshop was a definitive document on the issues pertaining to providing standard criteria for the evaluation of technical computer system security effectiveness. MITRE Corporation began work on a set of computer security evaluation criteria that could be used to assess the degree of trust one could place in a computer system to protect classified data. This outgrowth of recommendations from the document was also supported by the DoD Computer Security Initiative. The early concepts relating to computer security evaluation were thoroughly discussed at invitational workshops and symposia, where the invited participants represented computer security experts from industry and academia in addition to the government agencies.
Other nations had started work on their own standard criteria. To standardize the criteria these national authorities joined to form what is known as the common criteria.

1.1.2 Common Criteria

The Common Criteria for Information Technology Security Evaluation^[4] (Common Criteria – CC) is an international standard (ISO/IEC 15408)  for computer security certifications. The certifications are given on criteria bases. Labeled Security Protection Profile is a relevant certificate for MAC enabled systems. CC provides assurance that the process of specification, implementation and evaluation of a computer security product has been conducted in a rigorous and standard manner.

CC is a framework in which computer systems users can specify their security requirements with respect to functional and assurance goals. Then the vendors implement and define the security features of their products. The testing laboratories evaluate products to determine if they actually meet the standard minimum requirements of the certificate according to the criteria vendor claims.

2 Evolution of Mandatory Access Control

2.1  MAC on Opensource Distributions

In this section first we compare the MAC solutions on Linux based distributions in depth. Then we discuss the solutions available for other open source platforms based on BSD and Solaris. Some newer latest but maturing efforts like SMACK and Tomoyo are also touched for completeness.

2.1.2  MAC Mechanisms for the Linux Kernel

Mandatory access control on Linux platform started as patches available per solution. In order to mainstream it in the kernel an implementation independent security module was needed. This module would then be used by any MAC mechanism to register to it at a time. This modular security framework is known as the Linux security module framework.

2.1.2.1  Linux Security Module Framework
Earlier projects resorted to system call interposition to control kernel operations, which had serious limitations. ^[5] Secondly, there was lack for a standard mechanism and enhancements hooked to the kernel in a manner that only suited their own requirements. In addition, creating effective security module was a problematic task because the kernel had no infrastructure to mediate access of the security module to kernel objects.
To facilitate these issues the LSM^[6][7] project was developed as a lightweight, general purpose, access control framework for the Linux kernel. It enables many different access control models to be implemented as loadable kernel modules. Figure 2.1 LSM Framework is a visual representation. The LSM kernel modified the kernel in five primary ways.
• It adds opaque security fields as void* pointers, which enable security modules to associate security information with kernel objects.
• It inserts calls to security hook functions at various points in kernel to mediate access to kernel objects.
• It adds generic security system calls to implement new calls for security aware applications.
• It provides functions to allow kernel modules to register and unregistered themselves as security modules.
It moves most of the capability logic into an optional security module. LSM has an important feature that is module stacking but it pushes most of the work to modules themselves. Our future study may require this feature if we are to use integrity measurements for remote attestation. LSM kernel control flow, while assessing access control rights, first checks the DAC decision and if it is positive then LSM hook gives control to hook implementation, which mediates access between kernel data structures and the decision module, else system call is returned an error code.

Figure 2.1 LSM Framework

2.1.2.2  AppArmor

AppArmor^[8] previously known as SubDomain ^[9], is yet another implementation, which is not derived from a formal framework. It utilizes the concept of chroot jail with access control isolation enabled through program profiles. It provides a similar containment value to chroot, but without the need to physically move the application and its required resources into a separate container. AppArmor access control concentrates on file system resources, which means process transitions are not consider adequately.
AppArmor has an LSM compliant security module which is similar to SELinux in this regard. It uses LSM to communicate with securityfs, where it stores its security attributes and configurations. It uses profiles for the containment.

Figure 2.2 AppArmor Overview

2.1.2.2.1  Access Decision Mechanism

AppArmor’s decision facility is similar to SELinux as it is also LSM compliant. AppArmor is itself the core module, which handles most of the functionality. When a process invokes a system call, LSM hook implementation hooks the information from kernel data structures and provides it to the AppArmor module. Kernel data structures and identity of the subject and object, is checked against the profile of the application and reply is sent back via the hook function’s return to the system call.

2.1.2.2.2  Access Enforcement Mechanism

AppArmor earlier used system call modifications to check the confinement of processes. Now it uses the LSM module to perform these tasks. LSM is the leveraging medium between AppArmor module, system calls and kernel data structures.

2.1.2.2.3  Security Attributes and Policy Store

AppArmor uses securityfs, normally mounted on /sys/kernel/security to store its binary profile. The text files that make up the profile are parsed by apparmor_parse() called by the user space /ets/apparmor.d. The parser loads the binary policy onto securityfs via a sysctl() call from where AppArmor module loads it. By convention /etc/apparmor.d/hello_world will confine hello world.

2.1.2.3 GrSecurity

GrSecurity ^[10] is a suite of solutions that address different shortcomings of the operating system security. Thus, it can be stated that it does not implement any framework. It is a set of patches knitted in harmony with each other. It was originally a port of the security features of Openwall ^[11] but with time it has grown.
Philosophy behind GrSecurity is that currently operating systems avoid, identify and fix software bugs. The history of software development has proven that there are always going to be bugs in the software no matter what security measures are taken. GrSecurity as a solution detects, prevents and contains. Detection of vulnerabilities is available through auditing and logging of attacks, prevention by PaX (address space protection) with a combination of additional techniques.

Containment is enabled through access control lists. The ACL feature incorporates MAC into this enhancement and encourages a modular design for future extensions.
GrSecurity ^[10] being a knit of patches does not have a well defined kernel security module because it is inserted into various parts of the kernel to address the lack of current security mechanisms. Its ACL engine acts as the decision making facility and stores the ACL policy along with RBAC extensions.

2.1.2.3.1  Access Decision Mechanism

The ACL core of GrSecurity is the decision making facility, which gets requests from its enforcement mechanism. These requests contain identity of the requesting subject and the object being accessed. It utilizes hooks similar to what LSM provides, but are much more in number as it uses access control in multiple layers.

2.1.2.3.2  Access Enforcement Mechanism

GrSecurity enforcement being similar to SELinux and AppArmor as it has hook functions to mediate the control flow but it also has additional functionality. It has to manage the various security mechanisms. These are address space layout randomization, extensive auditing capabilities, netfilter module, stealth netfilter module, enhanced trusted path execution, OpenBSD randomness features at multiple layers, enhanced chroot jail, ptrace and Glibc restriction and various others.
These require lots of hooks and other mechanisms. This is the reason why it can’t be ported to LSM activated kernels.

2.1.2.3.3  Security Attributes and Policy Store

GrSecurity attribute management for ACL module is similar to LSM in that it does not centralize them. This was necessary for the various security features it supports. It extends various kernel data structures in order to facilitate all the patches it makes to the kernel.

2.1.2.4  RSBAC

Rule Set Based Access Control ^[12] is an open source security extension for the Linux type kernels based on the Generalized Framework for Access Control (GFAC) ^[13]. The GFAC framework targeted the integration of multiple policy components. This was achieved by modularizing the framework into access control enforcement, access control decision and access control information (security attributes) facilities. Access Decision Facility (ADF) implements the MAC security policies and a metapolicy to decide whether process’ requests satisfy those policies. Access Enforcement Facility (AEF) uses the ADF decisions to enforce the operations at system call level.
RSBAC is a direct implementation of the GFAC framework. It has been extended to supports more object types, includes generic list management and network access control, contains several additional security models and supports runtime registration of decision modules and system calls for their administration. The components ADF, AEF and ACI are hard linked into the kernel.

Figure 2.3 Overview and Flow Diagram of RSBAC

2.1.2.4.1   Access Decision Framework

RSBAC’s decision facility is ADF. With every security relevant system call, called by the subject to access an object, the AEF is invoked by intercepting the call. AEF compiles a request and sends it to the ADF for decision using an abstract function with relevant request type. The request has certain parameters; desired type of functionality is known from the request type, identification of the subjects and possibly some attributes of the object. These values are extracted by the AEF from the ACI against the subject and object.
Security policies are evaluated with respect to the policy rules for the request type by the ADF. ADF consults ACI for policy rules. When these rules are determined the meta-policy is evaluated to make the decision. Meta-policy uses the set of results from different security policies present to build the final result. Meta-policy is the union of the set of decision modules present in ADF.
ADF can be split into two parts: the main part, which handles the general work and the second part being the installed modules. The general work mainly consists of handling requests from AEF, dispatching it to the modules and performing generic logging. The modules compute the actual decisions against its policies and security attributes of the subject and object.

2.1.2.4.2   Access Enforcement Mechanism

RSBAC’s AEF enforces the decision based on the decision of ADF. Either the system call is permitted to do its function or an error is returned to the process with associated control data if necessary. In case of a positive result, ADF is notified so that ACI can be updated, the ADF tells the decision modules
to update their attributes from the data structures, sends an acknowledgement to AEF and then the object is accessed normally.
As AEF is embedded in the kernel subsystems it is the only RSBAC component, which cannot be modularized. It is hooked into several locations of the existing kernel code. Every security relevant system call and pseudo file handling function is extended by two calls to ADF. One is made before the original code, which requests for a decision and one after the original code to send update information to ADF. These two security-handling calls differ by functionality with the change in request type. Thus, it cannot be ported to LSM activated kernels. It would require a lot of change and loss in flexibility to implement new policy models.
2.1.2.4.3  Security Attributes and Policy Store

RSBAC’s ACI is used to store and maintain system values and data structures (for policy modules). System values portion stores and maintains label information for subjects and objects. It implements and store the contexts and data structures that are not handled by the kernel data structures.
Persistent attributes are additionally saved in the secondary storage. Dynamic, module specific data, like roles, user groups, access control lists and other relevant information are handled separately in the data structure portion. A file descriptor cache, fdcache, is used to reduce the performance hit because of the storage on secondary storage.

2.1.2.5  SELinux

NSA SELinux’s ^[14] origins are found in the research of an access control framework based on Distributed Trusted Operating System (DTOS)^[15] and Distributed Trusted MACH (DTMACH) ^[16], two MACH ^[17] based kernels. The resulting framework was named Flask ^[18], when ported to the Fluke ^[19] operating system. The Flask security framework is similar to GFAC where it separates the security policy decision from the enforcement mechanism.
The Security Server (SS), being the decision module, separates the policy logic with well defined interfaces for obtaining security policy decisions. The object managers are the enforcers for their specific objects (file system, process management, IPC, sockets, e.t.c.). There is an Access Vector
Cache (AVC), which is present inside the object managers. It caches access decisions for subsequent use by the object managers.
Flask being implemented on Fluke, micro kernel architecture, had to be adjusted with the monolithic design of Linux. Its implementation was a huge patch to the bare kernel, explicitly extending a lot of data structures it used internally to handle the operations concerning files, communication and other I/O. The object managers were ported as additional functionalities implemented inside the kernel subsystems. Security server is also part of the kernel now, which was originally a server in Flask.
After LSM became the standard access control farmework for the Linux kernel, SELinux adapted. Now SS is located as a LSM compliant module and kernel subsystems use the LSM features to communicate with the security server. AVC has also become centralized but an interface is provided in libselinux for user space object managers like the X server. The LSM architecture has made the SELinux design to become a bit scattered due to LSM’s coherence with the kernel.
Internal components, in addtion to SS, enforcement at kernel subsystems and AVC are network interface table (mapping of network interfaces to security contexts), network notificationcode (keep libselinux consistent with kernel module), SELinux pseudo file system (SS’s API to processes, selinuxfs) and hook functions’ implementation.
User space object managers are supported by libselinux. X server and Postgresql are already security enhanced servers. Policy Management Server (PMS), a user space feature lately added, can also be extended to a user space SS, which will reduce burden on kernel SS. Currently PMS only provides policy management in an object oriented manner but it also aims at handling a networked policy.

2.1.2.5.1 Access Decision Mechanism

SS is the decision facility for SELinux. It uses security labels to compute an access decision comparing an object’s label with the authorization level of a subject that attempts to access the object. To handle this objective there are two data types to map an object with its access rights. The security context is a string representation of the object’s rights, which is used by the SS to compute its decision against the policy. A security identifier (SID), an integer value, is mapped to the security context and is passed to the kernel subsystem for labeling of objects. The kernel subsystems pass SIDs to the SS so that it performs the translation to security context and computes the decision.

2.1.2.5.2 Access Enforcement Mechanism

The enforcement of policy decisions in SELinux, is accomplished in the kernel subsystems. When the SS returns the decision as a return to the hook function, the enforcement code either allows by letting the system call to continue or denies by returning an error code to it.
The kernel subsystems have the duty to label its objects with the SIDs passed from the security server. In case of subjects, they are non-persistent so these SIDs work fine for their data structures. But file system objects are persistent and labeling them means to release SIDs to user space. SELinux does not allow this. This problem is addressed in the next subsection.

2.1.2.5.3 Security Attributes and Policy Store

SELinux is straight forward in labeling non-persistent objects but allowing the labeling of persistent objects needs a solution. This is enabled by storing the security context in extended file system attributes (EA) ^[20]. These attributes are special settings stored in the vnode of the file, which is more
efficient by storing security attributes in an inode, for each file (an earlier solution), more localized manner. Although it is a logical solution but it has the limitation of which file systems can be used with SELinux. Currently ext2, ext3, ReiserFS and XFS file systems supports extended attributes.
The policy configurations are stored in selinuxfs, the pseudo file system. This is the binary policy, while the readable version is stored on secondary storage. It can be found in /etc/selinux/policy.conf. The generation of policy.conf is based on the base and loadable policy modules configurations.
Lately two new mechanisms have been introduced to with simplicity with high priority because normal desktop users find it difficult to manage the ones mentioned above. Following are work in progress and we will give a brief overview as they are not complete for our development purposes.

2.2  Other Maturing Mac mechanisms for Linux

2.2.1 SMACK

Smack ^[21] is a Mandatory Access Control mechanism designed to provide useful MAC while avoiding the pitfalls of its predecessors. The limitations of Bell & LaPadula are addressed by providing a scheme whereby access can be controlled according to the requirements of the system and its purpose rather than those imposed by an arcane government policy.
The complexity of Domain Type Enforcement is avoided by defining access controls in terms of the access modes already in use.

Table 2.1 Comparison of MAC mechanisms

2.2.2 Tomoyo Linux
Tomoyo Linux ^[22] is a path based MAC mechanism like AppArmor but it deals with domains rather than program based. The chain of execution defines the integrity of a domain from its history of execution and accesses to this domain’s resources are controlled via the behavior defined as a policy.
Tomoyo tries to avoid the complexity of SELinux by simplifying access control. The approach is to define a domain for the subject/process by a sequence of executed processes starting from the kernel, init and onwards to the subject process and associate all access rights with these domains. Tomoyo’s approach is feasible with the learning mode that it provides. It is a work in progress due to lack of tools when compared to others.

2.3   Non Linux, Opensource MAC Implementations

2.3.1 Trusted BSD

The TrustedBSD Framework for MAC ^[23] was first released with FreeBSD 5.0 distribution. It has matured to support policy modules that include rule-based filesystem firewall, TCP/UDP port ACLs, inter-user process controls and classic MAC policies such as MLS with compartments, Biba integrity policies.
Policy modules include cryptographic checksums on system services and utilities. SEBSD^[24] policies from the NSA FLASK based on SELinux are also ported FreeBSD.
The TrustedBSD MAC Framework was released in Mac OS X as of the Leopard distribution, where it is implemented for Seatbelt and other security services. The port of the MAC Framework was accomplished as part of the SEDarwin^[25], which also had a port of FLASK/SELinux to Mac OS X.

2.3.2 Trusted Solaris and FMAC

Labeled security has made it to the mainstream operating system therefore Sun Microsystems has included features of Trusted Solaris^[26], such as fine-grained access control, as part of the standard Solaris 10 release. This extension is called the Solaris Trusted Extensions. It is no longer necessary maintain a different kernel for labeled security environments. Solaris Trusted Extensions is an OpenSolaris project.
Solaris Trusted Extensions enforce a MAC policy on device access, file systems, networking, print and window management services and other operating system services. Sensitivity labels are assigned to objects of services, thereby establishing explicit information flow relationships between objects. Appropriate rules allows applications and users access to the objects’ methods and properties.
Lately the Flexible MAC (FMAC) project ^[27] has been initiated by the openSolaris community in the leadership of NSA, which adds the Flux Advanced Security Kernel architecture and Type Enforcement to OpenSolaris.

2.3.3 MAC on mobile devices

There have been researches, commercial and individual scholarly efforts to implement MAC on mobile devices. One of the first successful attempts was made by Montavista Linux ^[28]. Then Willis Vanderventer also ported it for GTA01 in a Google summer of code project ^[29], which we have used as a base source for our GTA02 targeted porting efforts.
In this section we will dive into the innovations of MAC on mobile platforms rather than porting issues which is discussed in implementation of SELinux on Openmoko in depth. First of all we will understand what the requirements are then followed by the available solutions.
The most important role that MAC plays is to provide isolation to stakeholder engines and resources with well defined interfaces. The MPWG ^[30] requires resources on the platform to be organized in isolated domains with internal interfaces creating sub-domains, with limited tiers. The software stack is supposed to be considered as entities that group into engines for stakeholders’ domain of authority. Engines communicate using defined interfaces.
MAC policy ensures that the software components, entities or data are accessed in a specified and trusted manner thus enabling a framework that gives integrity to the platform and its resources.

Figure 2.4 Mobile Phone Reference Architecture

Stakeholders are the autonomous entities that the resources of the platform belong to. In the TCG MPWG model the stakeholders are categorized as the mandatory and discretionary owners with respect to the engine types. An owner can have both types of engines as well. Then we can further categorize to device manufacturer, network operator, and general service providers as remote owners and the device user as local owner.

Figure 2.5 A generic Trust Engine and its interfaces

Consider the engine, in Figure 2.5, which can access services of other engines only through interfaces (1) and (6), and provides services to others only through interfaces (2) and (5).
Zhang et al. used the SELinux to form MPRA ^[31] as specified by the MPWG. In this work the MAC policy controls the information flows in such a way that stakeholder engines are isolated and least privileges are provided using interfaces between engines. They have also included a binary measurement agent that is used to measure the binary integrity using SELinux file system attributes and hooks.
Yet in another work he has demonstrated to use an integrity model for access control and on a mobile platform ^[32]. It demonstrates how object managers can be used to enforce better integrity of the platform.
PRIMA ^[33] is an approach where integrity measurement has been integrated with MAC mechanism of the platform. A Clark-Wilson lite model is used to enforce integrity based on filtering subjects. The filtering subjects are the object managers.

Nokia’s research on MAC ^[34] for mobile platforms uses two techniques, which are very different then other related literature on this topic. The first technique is to use a pre-configured lattice-based capability system for manufacturer provided operating system and its services. The second technique is the caging for untrusted programs. Caging allows the user to run these programs in an isolated environment. A cage being a virtual entity, which controls access to file system, networking and IPC for these programs according to the caging policy defined by the user at install time.

References

1. Trusted computer system evaluation criteria. Tcsec, DOD. s.l. : Technical Report 5200.28-STD, US Department of Defense, 1985
2. Scomp: A solution to the multilevel security problem. Fraim, LJ. 1983. Computer
3. Defense Data Network Security Architecture. Shirey, R.W. s.l. : ACM SIGCOMM Computer Communication Review, ACM, 1990. ACM SIGCOMM Computer Communication Review.
4. Common Criteria for Information Security Evaluation. [Online] http://www.commoncriteriaportal.org/.
5. Traps and pitfalls: Practical problems in system call interposition based security tools. Garfinkel, T.
6. Linux security modules: General security support for the linux kernel. Wright, C. and Cowan, C. and Smalley, S. and Morris, J. and Kroah-Hartman, G. s.l. : Proceedings of the 11th USENIX Security Symposium, 2002
7. Linux security module framework. Wright, C. and Cowan, C. and Morris, J. and Smalley, S. and Kroah-Hartman, G. s.l. : Ottawa Linux Symposium, 2002
8. AppArmor Security for Linux Application. Novel. [Online] Novel Inc. http://www.novell.com/linux/security/apparmor/.
9. Subdomain: Parsimonious server security. Cowan, C. and Beattie, S. and Kroah-Hartman, G. and Pu, C. and Wagle, P. and Gligor, V.
10. GrSecurity Papers. GrSecuirity. [Online] http://www.grsecurity.net/papers.php.
11. Openwall Project – Information Security Software. Openwall. [Online] http://www.openwall.com/.
12. Documentation. Rulset Based Access Control. [Online] http://www.rsbac.org/documentation.
13. The rule set based access control (rsbac) framework for linux. Ott, A. and Fischer-H{\\”u}bner, S. s.l. : Citeseer.
14. Publications. NSA Security Enhanced Linux. [Online] http://www.nsa.gov/research/publications/index.shtml.
15. Home Page. A Distributed trusted Operating System. [Online] http://www.cs.utah.edu/flux/fluke/html/dtos/HTML/dtos.html.
    
16. Assuring distributed trusted mach. Fine, T. and Minear, SE. s.l. : IEEE Computer Society Symposium on Research in Security and Privacy., 1993
17. Home Page. The MACH project. [Online] http://www-2.cs.cmu.edu/afs/cs/project/mach/public/www/mach.html.
18. Flux Advance Security Kernel. Flask. [Online] http://www.cs.utah.edu/flux/fluke/html/flask.html.
19. Flux Micro Kernel Architecture. [Online] http://www.cs.utah.edu/flux/fluke/html/index.html.
20. Linux Extended Attributes and ACLs. [Online] http://acl.bestbits.at/.
21. schaufler, Casey. Smack White paper. [Online] http://www.schaufler-ca.com/data/SmackWhitePaper.pdf.
22. Tomoyo Linux Wiki. TOMOYO Linux : Behavior oriented system analyzer and protector. [Online] http://tomoyo.sourceforge.jp/wiki-e/.
23. Documentation. The TrustedBSD Project. [Online] http://www.trustedbsd.org/docs.html.
24. SE-BSD. The TrustedBSD Project. [Online] http://www.trustedbsd.org/sebsd.html.
25. SE-Darwin. Security Enhanced Darwin. [Online] http://sedarwin.org/.
26. Trusted Solaris Operating Environment – Documentation. Trusted Solaris Operating System. [Online] http://www.sun.com/software/solaris/trustedsolaris/documentation/index.xml.
27. Project FMAC: Flexible Mandaroy Access COntrol. [Online] http://hub.opensolaris.org/bin/view/Project+fmac/.
28. Datasheet. Montavista – Mobilinux. [Online] http://www.mvista.com/download/MontaVista-Mobilinux-5-datasheet.pdf.
29. Openmoko-Selinux. GSoC. [Online] http://code.google.com/openmoko-selinux/.
30. Mobile. Trusted Computing Group. [Online] http://www.trustedcomputinggroup.org/developers/mobile.
31. A trusted mobile phone reference architecturevia secure kernel. Zhang, X. and Ac{\i}i{\c{c}}mez, O. and Seifert, J.P. s.l. : Proceedings of the 2007 ACM workshop on Scalable trusted computing, 2007.
32. Building Efficient Integrity Measurement and Attestation for Mobile Phone Platforms. Zhang, X. and Ac{\i}i{\c{c}}mez, O. and Seifert, J.P. s.l. : Security and Privacy in Mobile Information and Communication Systems: First International ICST Conference, MobiSec 2009, Turin, Italy, June 3-5, 2009, Revised Selected Papers.
33. PRIMA: policy-reduced integrity measurement architecture. Jaeger, T. and Sailer, R. and Shankar, U. s.l. : Proceedings of the eleventh ACM symposium on Access control models and technologies, 2006.
34. Mandatory Access Control for Mobile Devices. Ekberg, Elena Reshetova and Jan-Erik. s.l. : Nokia Research Center Helsinki. NRC-TR-2008-010.

In this documentation we cover the proper deployment of a TPM emulator on the software stack of Openmoko device. This task is a deliverable in the project DBAMP funded by ICT R&D accomplished at SERG.

Contents

1. TPM/MTM Emulators
2. Obtaining Tool Chain
3. Installation of TPM Emulator
4. Installation of TPM Tools
5. Installation of Trousers
6. Trouble shooting
7. References
    

1. TPM/MTM Emulator
Software based Emulator for TPM[5]/MTM is a flexible simulator of the hardware TPM/MTM providing a strong platform for testing and debugging tool for programmers. The emulator is portable to different operating systems like Linux, Mac, Windows etc, and provides compatibility to common Software’s.

2. Obtaining Tool Chain
You need a tool chain[6] to cross compile the libraries and to setup environment for cross compilation. The Tools-Chain’s Cross-compiler will compile the source code from native machine (x86 in our case) to a target platform (ARM).  To Download the tool chain Click here.

 Extract the contents of the archive to the root directory and the files will get to /usr/local/openmoko.
 

3.Installation of TPM Emulator
First we have to download the TPM emulator [7]from the site given below
http://tpm-emulator.berlios.de/download.html
To use the TPM emulator [7]you have to perorm the following step.The downloaded file is in tar.gz form.First unextract it through the command given below
 
#tar -xvzf tpm_emulator-X.Y.tar.gz
 
Then go to the tpm emulator directory through the command
 
# cd tpm_emulator-X.Y
 
In tpm emulator directory we have to make another directory named as build through the command
 
# mkdir build

Go in to build directory through the command given below
 
# cd build 
# . /usr/local/openmoko/arm/bin/setup-env
# . /usr/local/openmoko/arm/envirnoment-setup
 
 Now execute this command in terminal

# cmake ../
 
After cmake you have to install libgmp3-dev otherwise it will give you error.
 
#apt-get install libgmp3-dev
 
Then excute the following command
 
# make
# make install
 
To start using the tpm emulator in linux you have excute the following command
 
#depmod -a(To resolve the dependencies)
# modprobe tpmd_dev
# tpmd
 
4.Installation of TPM Tools 
First we have to download the TPM Tools [8]from the site given below
http://sourceforge.net/projects/trousers/files/tpm-tools/1.3.5/tpm-tools-1.3.5.tar.gz/downloadTo

use the TPM Tools you have to perorm the following step.The downloaded file is in tar.gz form.First unextract it through the command given below
 
#tar -xvzf tpm_tools.tar.gz
# . /usr/local/openmoko/arm/bin/setup-env
# . /usr/local/openmoko/arm/envirnoment-setup
# ./configure
#make
#make install
 
 
5.Installation of Trousers
 First we have to download the Trouser[9] from the site given below
http://sourceforge.net/projects/trousers/files/To use the Trousers you have to perorm the following step
 
The downloaded file is in tar.gz form.First unextract it through the command given below
 
#tar -xvzf trouser-X.Y.tar.gz
 
Then go to the trouser directory through the command
 
# cd trouser-X.Y
# . /usr/local/openmoko/arm/bin/setup-env
# . /usr/local/openmoko/arm/envirnoment-setup
# ./configure
#make
#make install
 

6.Trouble Shooting

7.References
 
[1]http://www.trustedcomputinggroup.org/
[2]http://www.trustedcomputinggroup.org/resources/tpm_main_specification
[3]http://en.wikipedia.org/wiki/Cryptography
[4]http://en.wikipedia.org/wiki/Openmoko
[5]http://en.wikipedia.org/wiki/Trusted_Platform_Module
[6]http://downloads.openmoko.org/developer/toolchains/openmoko-i686-20090323-armv4t-linux-gnueabi-toolchain-openmoko.tar.bz2
[7http://tpm_emulator.berlios.de/                                                                                                                                                                                                                                                                                                                   [8]http://sourceforge.net/projects/trousers/files/tpm-tools/1.3.5/tpm-tools-1.3.5.tar.gz/download
[9]http://sourceforge.net/projects/trousers/files/

A general notion of discretionary security suggests that DAC ^{[1] [2]} is any security policy or a security mechanism where ordinary users are involved in defining the security policy. Discretionary access control (DAC) is defined by the Trusted Computer System Evaluation Criteria ^[3] as “a means of restricting access to objects based on the identity of subjects and/or groups to which they belong. The controls are discretionary in the sense that a subject with certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject (unless restrained by mandatory access control)”.
In discretionary access control individual users can grant or deny permissions to other programs and applications on the platform, on the objects that are owned by them. In most cases the authorizations are stored in an access control matrix and the access requests from users are checked against the corresponding authorizations in the ACM. Access control matrix and its various implementations are discussed in the following subsections.

Access Control Matrix

An Access Control Matrix or Access Matrix ^[4] stores the rights and permissions of each subject with respect to every object in the system and represents an abstract model of permissions. If the ACM is literally implemented as it is then the resulting data structure will have excessive memory requirements. Therefore to make it more practical some variations of the access matrix are implemented in the real world which are slightly different from its literal representation, but nonetheless serve the same purpose. The variations of access control matrix include capability-based systems and access control lists.

Implementation of Access Control Matrix

Access Control Lists

An access control list (ACL) is a list of permissions associated with an object. An ACL is a table that specifies which access rights each user has on a particular system object. The list has an entry for each system user and his or hers corresponding access privileges e.g. read, write or execute. When a user or a process tries to access an object the operating system lookup the entries in the ACL defined for that particular object and determines whether the user or the process is authorized to perform underlying operation.

Capability based systems

Capability-based systems use capabilities as a token of authority in order to determine the authorization of users. A capability refers to an object and the set of access rights that are associated with it. A user program will use a capability to access an object and may also share its own capability with other programs and also with the operating system infrastructure, which provides the primary means of granting and distributing access rights within the system.
Capabilities achieve their objective of improving system security by being used in place of forgeable references. A forgeable reference identifies an object such as the file path of an object, but does not specify which access rights are appropriate for that object. If a user program or a processes possesses a capability entitles it to use object that the capability refers to and to exercise the rights that it associates with the object.

References

1. Access control: Principles and practice. Sandhu, R.S. and Samarati, P. New York : Communications Society of Institute of Electrical and Electronics Engineers, 1994, IEEE Communications Magazine, Vol. 32, pp. 40–49.
2. Issues in discretionary access control. Downs, D.D. and Rub, J.R. and Kung, K.C. and Jordan, C.S. s.l. : IEEE Computer Society, 1987, Tutorial computer and network security.
3. Trusted computer system evaluation criteria. Qiu, L. and Zhang, Y. and Wang, F. and Kyung, M. and Mahajan, H.R. s.l. : Citeseer, 1985, National Computer Security Center.
4. Protection. Lampson, B.W. s.l. : ACM, 1974, ACM SIGOPS Operating Systems Review, Vol. 8, pp. 18–24.

Mandatory access control (1) aims to improve the security of computer systems by overcoming the weaknesses found in the discretionary access control systems. One of the major weaknesses of DAC is that it treats all of the processes of a user equally and does not differentiate between them i.e. all of the processes of a user have exactly the same permissions as the user himself. This creates several problems in the real world where malicious programs may exploit the permissions and privileges of a user on whose behalf they are being executed within the system, Trojan horses can easily exploit this weakness, -Whereby an unsuspecting user executes the malicious application as a result of which the security of the system is compromised.

A mandatory security policy is considered to be any security policy where the definition of the policy logic and the assignment of security attributes are tightly controlled by a system security policy administrator. MAC enforces access control on the basis of the labels assigned to subjects and objects. A mandatory access control policy specifies how subjects may access objects under the control of the operating system.
In any system which supports mandatory security, some applications require special privileges in the mandatory policy in order to perform some security-relevant function. Such applications are frequently called trusted applications because they are trusted to correctly perform some security-related function and because they are trusted to not misuse privileges required in order to perform that function. If the mandatory security mechanisms of a secure operating system only support coarse grained privileges, then the security of the overall system may devolve to the security of the trusted applications on the system. The mandatory security mechanisms of most of the operating system use the principle of least privilege to reduce the dependency on trusted applications. Type enforcement is an example of a mandatory security mechanism which is used to limit trusted applications to the minimal set of privileges required for their function and also to confine the damage caused by any misuse of these privileges.
MAC is often used to provide domain isolation, a mechanism used to rigorously confine an application to a unique security domain that is strongly separated from other domains in the system. As a result any damage arising from the misuse or exploitation of an application is restricted to a single security domain without disrupting the functionality applications running in different domains. This confinement property is critical to controlling data flows in support of a system security policy. In the case of personal computing systems, where the user may be the system security policy administrator, mandatory security mechanisms are helpful in protecting against flawed or malicious software.

Multi Level Security

Multilevel security (MLS) is used to process information with different sensitivities and to prevent unauthorized access to information. MLS allows the information to flow freely between recipients in a computing system who have appropriate security clearances while preventing the leakage of information to unauthorized users. MLS is most commonly used in military and government applications.
The notion of MLS seems very simple but unfortunately it is not easy to implement modern in computer systems effectively, where the sheer complexity of information flows within the system makes it impossible to prevent the leakage of data from high classification levels to lower ones. Furthermore more often than not MLS is not reliable and suitable enough for truly large scale systems.
Various security mechanisms are based on MLS each serves a different purpose e.g. confidentiality or integrity of information etc. Lattice based access control systems, Bell-La Padula, Biba and clark Wilson models may be viewed as variations of the multi-level security model.

Lattice based access control

Lattice based systems ^[2][3] are concerned with preserving the confidentiality and integrity of information flows with in a system and were formally defined by Denning. Lattice-based access control (LBAC) is a complex access control mechanism based on the interaction between any combination of objects and subjects. A lattice is used to define the levels of security that an object may have and that a subject may have access to. The subject is only allowed to access an object if the security level of the subject is greater than or equal to that of the object.

Bell-La Padula

The Bell-La Padula model ^[4] focuses on the confidentiality of data and access to classified information and aims to protect information from unauthorized subjects. Bell-La Padula is inspired from the hierarchy and information flow rules of military organizations and is the predominant form of access control in governmental and military applications. Access decision is taken on the basis of the security labels that are assigned to subjects and objects of a system. The security label of the subjects is known as “Security clearance” while the security label of an object is termed as its “Security classification”. The label of an object shows the sensitivity of the information contained within, while the label of a subject denotes the extent of sensitive information that can be accessed e.g. Top Secret, Secret, Classified, Unclassified, Public etc.
The model defines two mandatory access control (MAC) rules and one discretionary access control (DAC) rule with three security properties:
• The Simple Security Property: a subject at a given security level may not read an object at a higher security level (no read-up).
• The *-property: a subject at a given security level must not write to any object at a lower security level (no write-down). The *-property is also known as the Confinement property.
• The strong *-property: an alternative to the *-Property in which subjects are only allowed to write objects at their own security level. Thus, the write-up operation permitted in the usual *-Property is not present.
The transfer of information from a document of higher security level to a document in the lower security levels may happen in the Bell-La Padula model via the concept of trusted subjects. Trusted Subjects are not restricted by the *-property while un-trusted subjects are. Trusted Subjects must be shown to be trustworthy with regard to the security policy.
With Bell-La Padula, users can create content only at or above their own security level e.g. users having the security clearance of “secret” can create documents with security classification of “secret” or “top-secret”, but they are not allowed to create public files. While at the same time users can view content only at or below their own security level.

Biba

The Biba Model or Biba Integrity Model describes a set of access control rules designed to ensure data integrity. Data and subjects are grouped into ordered levels of integrity. In contrast to the Bell-La Padula model, subjects are not allowed to read information from the lower security level so users can only view content at or above their own integrity level. While at the same time writing to higher levels is prohibited.
In general the model was developed to circumvent a weakness in the Bell-La Padula Model which only addresses data confidentiality. The rules defined by the Biba model are the reverse of the Bell-La Padula rules:
• The Simple Integrity Axiom states that a subject at a given level of integrity must not read an object at a lower integrity level (no read down).
• The * (star) Integrity Axiom states that a subject at a given level of integrity must not write to any object at a higher level of integrity (no write up).

Low Water-Mark Model

Low Water-Mark also serves to protect the integrity of objects and information in a system and its rules are similar to the Biba model with one major difference ^[5]. The LOMAC model allows a subject to decrease its integrity level in order to read information from objects of lower integrity in which case the subject having decrease its integrity will not be able to write to the higher integrity objects so as to preserve their and to prevent the low integrity information from flowing into the higher integrity objects.

Clark Wilson

The Clark-Wilson integrity ^[6] model provides a foundation for specifying and analyzing an integrity policy for a commercial application system. The rules of Clark Wilson’s model are based on commercial data processing practices and are primarily concerned with formalizing the notion of information integrity.
Information integrity is maintained by preventing corruption of data items in a system due to either error or malicious intent. An integrity policy describes how the data items in the system should be kept valid from one state of the system to the next and specifies the capabilities of various principals in the system. The model defines enforcement rules and certification rules.
In contrast to the Bell-La Padula model, Clark-Wilson is more clearly applicable to business and industry processes in which the integrity of the information content is paramount at any level of classification.
The model uses two categories of mechanisms to realize integrity: well-formed transactions and separation of duty. The core of the model is based on the notion of a transaction.
• A well-formed transaction consists of a series of operations that transition a system from one consistent state to another consistent state and is defined as a transaction where the user is unable to manipulate data arbitrarily, but only in a constrained manner that preserves or ensures the integrity of the data. Well-formed transactions ensure that only legitimate actions can be executed so that the data is accurate and consistent to what it represents in the real world.
• The principle of separation of duty states no single person should perform a task from beginning to end, but should be divided among two or more people to prevent fraud by one person acting alone. According to this principle the certifier of a transaction and the implementer be different entities.
• In this model the integrity policy addresses the integrity of the transactions.
The model contains a number of basic constructs that represent both data items and processes that operate on those data items. Clark-Wilson model partitions all data in a system into two categories -constrained data items (CDI) and unconstrained items (UDI), data items for which integrity must be ensured. The (CDI) are objects that the integrity model is applied to and (UDI) are objects that are not covered by the integrity policy. Two procedures are then applied to these data items for protection. The first procedure integrity verification procedure (IVP), verifies that the data items are in a valid state. The second procedure is the transformation procedure (TP) or well-formed transaction, which changes the data items from one valid state to another. If only a transformation procedure is able to change data items, the integrity of the data is maintained.
Two types of rules have been defined in the Clark-Wilson model to ensure that integrity is preserved and achieved. These two types of rules are called integrity-monitoring (certification rules) and integrity-preserving rules (enforcement rules). The integrity-monitoring rules are enforced by the administrator and the integrity-preserving rules are enforcement rules guaranteed by the system.

Chinese wall policy

The Chinese wall policy caters to the information flow requirements of commercial sector organizations in general and financial sector in particular. The rules of Chinese wall can be easily understood by taking the example of an analyst working for a financial sector organization which provides services to various corporations. In such a scenario the financial organization has to adhere to rigorous rules and follow certain guidelines that have been devised to protect the confidential data of its clients, which in most cases are competitors of each other, to prevent the business secrets of one from falling into the hands of another. This means that the organization must not allow the analyst to advise a corporate client if he happens to have knowledge of or access to data and information of its competitors. Therefore the analyst is only allowed to advise and guide those organizations who are competitors of each other.
The Chinese wall policy works by dividing datasets into groups or categories, the group is called a “Conflict of interest class”, the conflict of interest class in general represents a business sector. A subject can access at most on dataset from any such conflict of interest class, therefore in the Chinese wall policy the access history of a subject determines what kind of objects or datasets he is allowed to access. If a subject has accessed a dataset from one conflict of interest class then any subsequent attempts to access other datasets from the said conflict of interest class are denied. Initially the users has the choice to access any dataset, once the initial choice has been made and a dataset is accessed then the user cannot access other datasets that belong to the same conflict of interest class, hence a wall is created around the dataset that has been accessed and the datasets that belong the same conflict of interest class are viewed as being on the wrong side of the wall, furthermore datasets belonging to other conflict of interest classes can be accessed by the user. As the user accesses datasets from other conflict of interest classes the wall changes its shape to include the newly selected dataset and the remaining items of its conflict of interest class also become inaccessible as they are now also on the wrong side of the wall. Therefore access to an object is allowed if it belongs to the datasets that have already been accessed and are therefore inside the wall, or if the object belongs to a dataset whose conflict of interest class has not been accessed before by the user.
In United Kingdom the Chinese Wall requirements of the UK Stock Exchange must be implemented either manually or via automated means and are mandatory as per law ^[7].

References:

1. Trusted computer system evaluation criteria. Qiu, L. and Zhang, Y. and Wang, F. and Kyung, M. and Mahajan, H.R. s.l. Citeseer, 1985, National Computer Security Center.
2. A lattice model of secure information flow. Denning, D.E. s.l. : ACM New York, NY, USA, 1976.
3. Lattice-based access control models. Sandhu, R.S. 11, s.l. : IEEE computer, 1993, Vol. 26.
4. Computer security model: Unified exposition and multics interpretation. Bell, D.E. and LaPadula, L.J. s.l. : MITRE Corp., Bedford, MA, Tech. Rep. ESD-TR-75-306, June, 1975.
5. Biba., K. J. Integrity Considerations for Secure Computer Systems. . Bedford, Massachusetts : USAF Electronic Systems Division, Hanscom Air Force Base, April 1977. Technical Report ESD-TR-76-372
6. A comparison of commercial and military computer security policies. Clark, D.D. and Wilson, D.R. s.l. : NATIONAL INSTIUTE OF STANDARDS & TECHNOLOGY, 1989, Vol. NIST SPECIAL PUBLICATION SP.
7. The Chinese wall security policy. Brewer, D.F.C. and Nash, M.J. s.l. : Proceedings of the 1989 IEEE Symposium on Security and Privacy, 1989.

The idea of role based access control was first introduced during the 1970’s and this model is most widely implemented on computer systems where the number of users is relatively large, where it became increasingly difficult for a system administrator to define and assign permissions to each and every user of a computer system. RBAC was introduced to streamline the cumbersome process of security management roles are used to group users with similar permissions together, permissions are then assigned to the roles which are inherited by the users who are its members, thus making the lives of system administrators much easier and simplifies the task of permission management.
Generally the roles that are created on a system or a group of systems vary from organization to organization and usually depend on their job functions. When roles are created and permissions have been granted to them these roles can be assigned to users based on their responsibilities and authorizations. Roles are very flexible and it is easy to add or remove users from roles. It’s easy to assign new permissions as well as to revoke permissions from the roles within a system.
In RBAC the decision to allow access to a piece of data depends upon the role of the user and the permissions associated with that role. Hence the policy enforced by an RBAC access control system depends upon how the owner or the security administrator of the computing platform configures the various components of RBAC including the roles their permissions and the assignment of roles to the users, as well as the hierarchy of the roles and the relationships among them.

• http://imsciences.edu.pk/serg/2010/07/antlr-introduction/
• http://imsciences.edu.pk/serg/2010/07/setting-up-antlr-3-1-in-eclipse-3-5-for-windows/
• http://imsciences.edu.pk/serg/2010/07/grammer-file-syntex-symentics-of-our-policy-writing-with-antlr/

In this grammar file we do our semantic analysis, by walking and evaluating the nodes, of the AST tree, generated in our grammar file.

Figure 1. A screenshot of the tree of a statement.

tree grammar StatementWalker1;

options {

language = Java;

tokenVocab = XL1;

ASTLabelType = CommonTree;

}

@header{

package com.fawad.policywritingtool;

}

policy

: (mode ‘(””‘ appname ‘”‘ ‘as’ app ‘,’ ‘”‘ permname’”‘ ‘as’ perm ‘)’ ‘:’

statement+ ‘->’ policyeffect ‘(‘app ‘,’ perm ‘)’ ‘;’ )+

;

mode

: RES

;

appname

: IDENT(‘.’ IDENT | ‘_’ IDENT)+

;

app

: IDENT+

;

method

: IDENT+’()’

;

permname

: IDENT(‘.’ IDENT | ‘_’ IDENT)+

;

perm

: IDENT+

;

An integer ‘result’ is returned when the statement is evaluated

statement returns [int result] :    e=expression  { result = e; }

;

Following are the operators and their respective implementation in the walker

expression returns [int result]

: ^(‘AND’ op1=expression op2=expression ) { if(op1==1 && op2 == 1) result =1; else result =0;}

|^(‘OR’ op1=expression op2=expression ) { if(op1==1 || op2 == 1) result =1; else result =0;}

|^(‘>’ op1=expression op2=expression) { result= op1 > op2?1:0; }

| ^(‘<’ op1=expression op2=expression) { result= op1 < op2?1:0;}

| ^(‘>=’ op1=expression op2=expression) { result= op1 >= op2?1:0;}

| ^(‘<=’ op1=expression op2=expression) { result= op1 <= op2?1:0;}

| ^(‘=’ op1=expression op2=expression) { result= op1 != op2?1:0;}

| ^(‘!=’ op1=expression op2=expression) { result= op1 != op2?1:0;}

| ^(‘+’ op1=expression op2=expression) { result = op1 + op2; }

| ^(‘-’ op1=expression op2=expression) { result = op1 – op2; }

| ^(‘*’ op1=expression op2=expression) { result = op1 * op2; }

| ^(‘/’ op1=expression op2=expression) { result = op1 / op2; }

| ^(‘%’ op1=expression op2=expression) { result = op1 \% op2; }

| ^(NEGATION e=expression) { result = -e;}

| TRUE{ result = 1;}

| FALSE{ result = 0;}

| INTEGER { result= Integer.parseInt($INTEGER.text); }

;

Policy effect returns an integer ‘res’ with the value ‘1′ for allow and  ’0′ for deny

policyeffect returns [int res ]

: ALLOW {res= 1 ;}

| DENY {res= 0 ;}

;

Courtesy of Fawad, Owais, & Mir Nauman Tahir

Introduction

The mobile devices and their related technologies have been developing significantly and have changed a lot during the last decade. With the passage of time the computing capabilities of these mobile devices have been increasing rapidly, which are now comparable to the personal computers that existed in the market five to eight years ago. The usability of these devices has also improved a great deal along with their computing power and there has been a considerable change in the way these mobile devices are deployed and the way people use them.
As a result these mobile devices have evolved from being devices dedicated only for communication purpose to general purpose computing platforms. Therefore the use of these mobile devices is not limited to making calls and sending text messages only, instead they are being used to consume a wide range of services e.g. browsing the web either using GPRS or Wi-Fi, running various softwares that can be used to carry out business transactions or sending emails, creating spreadsheets, presentations, word documents. Besides this these devices also host a variety of multimedia capabilities such as camera and imaging capabilities, music and jukebox capabilities, movies and video playback as well as a gaming capabilities etc. Therefore Mobile phones are now sophisticated smart phones that provide services beyond basic telephony, such as supporting third-party applications. These third-party applications may very well be security-critical in some cases, such as mobile banking, online business, e-governance and other commercial applications, other third party applications may be untrusted, such as games that have been downloaded from the internet.
As the nature of the usage of these devices has changed so have their security requirements. The nature of security threats encountered on the mobile devices is very much different from those found in the PC world. The major threat comes from the applications that are downloaded and executed on the mobile device. The malicious application can be downloaded by the user on to the device via GPRS, Wi-Fi, or may be received via Bluetooth from other mobile devices. These malicious applications might potentially damage the personal data of the user on the mobile device such as deleting the address book and the messages from the inbox, malicious applications can also delete or overwrite sensitive operating system files, a malicious application may send SMS or make voice calls to premium numbers without the consent of the user hence incurring a huge economic cost to the user.
More and more applications are being developed by third party application developers for these powerful mobile devices which are easily available for download from the internet. however the introduction of third party applications on the mobile phone gives rise to some very critical security concerns as these phones host a variety of trusted code and sensitive information that needs to be protected from third party applications and untrusted code. There is no shortage of sensitive applications such as the banking applications for mobile phones, which are valuable targets for the cyber criminals who discover and exploit any vulnerability that might exist on the platform. Cyber criminals have exploited many vulnerabilities of the Symbian platform to launch various kinds of worm attacks on the devices that run the Symbian operating system. As the Linux and Windows based smartphones grow in numbers, it is eminent that they are an obvious target for malwares. As a result of these developments, research activities in the field of mobile platform’s security has gained momentum as researchers try counter the threats faced by the trusted applications running on these versatile devices and to alleviate the concerns of their users.
In order to counter the threats faced by the mobile devices various access control mechanisms are deployed to protect the services running on the device as well as the data of the user stored on these devices. Discretionary access control is the predominant form of security mechanism that exists on an overwhelming majority of mobile phones. While this type of access control mechanism is simple however past experience has shown that it is insufficient to cater the security needs of an open platforms such as Linux and windows based operating systems for mobile phones. As more and more vulnerabilities have been discovered in mobile phones, researchers in the field of mobile phones security have taken rigorous initiative to counter the threats that are now staring in their eyes as a result research in this particular field is gathering momentum to keep up with the challenges that are arising in the wake of rapid advancements in the technology of mobile phones including the software and the hardware.
Recent research work has focused on leveraging the features of Mandatory access control which provides the foundation needed to build a secure environment where trusted and untrusted code co-exist on the platform in such a manner that the trusted code and sensitive data is protected from untrusted applications and unauthorized access.
The report is organized as follows the introduction section gives a general overview of the existing access control models including mandatory access control. The second section outlines the various implementations of mandatory access control mechanisms on PC and mobile platforms. The third section provides detailed information about SELinux while the last section provides technical details about the process of porting SELinux to the linux based openmoko mobile phone.

Access Control Systems

Access control system ^[1][2] determines the privileges that a user or a program has on the system and consequently determines the operations that can be performed by them. Access control systems regulate access to the resources of a system in order to ensure that the users of a computing platform and the processes running on it access these resources in a controlled and authorized manner. The access control system limits the actions of the users and the programs on the system based on the permissions that have been assigned to them in order to protect the system and its resources from being compromised and to counter the threats originating from malicious users as well as malware applications.
The access control system encompasses two key concepts of an access control policy and an access control mechanism. An access control policy provides high level guidelines about what type access is allowed and how the access control decision is going to be made by the reference monitor. Access control mechanism consists of a combination of hardware and software components of the system that are used to implement the access control policy.
An important concept associated with the access control mechanisms is that of a reference monitor ^[3]. The reference monitor intercepts and regulates the requests of users and applications to access various objects or resources in the system. The reference monitor then mediates the access requests and takes the decision of whether to allow or deny access based on the security policy of the platform which determines whether the user or the application is authorized to perform the underlying action on specified object.
Although access control mechanisms are vital for preserving the security of the computing platform however to be effective and to prevent the security of the system from being compromised, these mechanisms have to work in tandom with other security services of the platform such as authentication, auditing and administration. While the access control mechanism controls the actions that a user is allowed to perform, the authentication mechanism is responsible for identifying the user usually with the help of a username and a password, therefore the access control mechanism assumes that the user has been successfully authenticated prior to enforcement of the access control by the reference monitor.
All the actions of the users that are allowed by the reference monitor or denied are also examined by the auditing services of the platform and logs the relevant activity of the various users and applications running on the system.
Three types of access control policies are most commonly used in computing systems around the world
• Discretionary access control
• Mandatory access control
• Role based access control

Effective access control systems in today’s computing environments use a combination of these security policies in the following subsections provide a brief introduction to the afore mentioned security policies.

References

1. Access control: The neglected frontier. Sandhu, R. s.l. : Springer, 1996, Lecture Notes in Computer Science, pp. 219–227.
2. Access control: Policies, models, and mechanisms. Samarati, P. and De Capitani di Vimercati, S. s.l. : Springer, 2001, Lecture Notes in Computer Science, pp. 137–196.
3. Computer Security Technology Planning Study. Anderson, J.P. and others. s.l. : ANDERSON (JAMES P) AND CO FORT WASHINGTON PA, 1972.

Smartphones with open operating systems are getting popular with the passage of time. Increased exposure of open source smartphones also increased the security risk.  Android is one of the most popular open source operating system for mobile platforms. Android provide a base set of permissions to protect phone resources. But still the security area is underdeveloped. This survey is about the current work done on the Android operating system. Some of the techniques, which can give a positive edge to the security area, are analyzed in the present survey paper. These techniques are basically to provide a better security and to make the Android security mechanism more flexible. As the current security mechanism is too rigid. User does not have any control over the usage of an application. User has only two choices, a) allow all permissions and application will install, b) deny all permissions and installation will fail.

I.Introduction

Smartphones are spreading day by day all over the world. However its security is still a big issue. The increased capability and computational power of smartphones increased the interest of developers towards the development of applications for this next generation platforms. Smartphones brings the mobility of traditional cell phones and the power of desktop computers in a single package. Weather updates, shopping, e-ticketing, mobile health and social networking, all on single platform with the additional factor of mobility. Where, the term mobility introduces, so the security and privacy becomes a major issue over there. In this emerging environment, applications are not stand alone. Applications expose its specific features to rest of applications installed on the same platform. And also use features of its neighbour applications. Where, this feature increases the functionality of an application, thereby it also welcomes some security threats. Which can’t be ignores in order to achieve a secure platform.

In the present environment of mobile platforms, Android is quite popular and famous open source and well customizable software package for cell phone devices. Android is a Google operating system for mobile platforms with the basic functionality of system utilities, middleware in form of VM and some core application like browser, dialler, calculator and some others as well.

The present applications are not enough to take full benefit of Android. So, third party developers create applications and launch it to the applications of Android Market. Users are able to download and install the launched applications. This is a sign of high availability of applications for users. But at the same time the user need trust full applications, which do not harm their privacy and security issues. Keeping this issue in mind, every application asks for permissions from the user during the time of installation. User has only two choices, either to grant all the required permissions and the application will be install. And once the permissions are granted, Android does not provide any facility to revoke those permissions, unless the user uninstalls the application.  If user denies the permissions so the application will fail installation. There is no mechanism to allow some permission and deny the rest.

Consider a weather update application that reads user’s location from his phone and provide weather updates on the base of time and location. Location information can be received by two ways. Either by taking location information automatically from GPS or the user himself enters his location where GPS is not available. At the time of installation, this application will ask for location permission. If the user grants the permission to the application so, the application will get install. The drawback is that, the application can collect the user location anytime, even user do not wish so. And if the user does not grant permission to the application during installation, so the application will not be install.

II. Background

Android is a Google operating system launched for mobile platforms. The current architecture of Android is explained below:

2.1 Android Layered Architecture

Android architecture composed of four layers. Application layer on top and the rest of three layers are beneath, application framework, Android runtime and Linux kernel.

Linux kernel is used as an abstraction the hardware and the software.

Android runtime’s is a core component of Dalvik virtual machine. Each Android process runs in a separate instance of Dalvik virtual machine.

Application Framework is a built in toolkit. It provides different packages of services to applications.

2.2    Android Application Structure

Android applications are written in java. But Android does not support execution of java byte code. Dx tool is used by Android for the conversion of java code into Dalvik byte code. Every application is assign with a unique Linux user ID call as UID. This functionality allows Dalvik to run multiple applications in a separate process. Those applications who run in a single process, must share a single UID. Otherwise every application will have a separate UID.

Figure 1: Typical ICC between Activities, Services, Content Providers and Broadcast Receivers

2.3    Android’s   Components

Android composed of basic four components. ICC is used for communication between components.

i) Activity: Activity is a visual screen for interaction of user with the application. Depends upon design, an application may consists of one or more activities

ii)Service: Service do not have a visual interface, it runs in the back ground, like play back music and fetching data from the network.

iii)Broadcast Receiver: Broadcast receiver receive broadcast announcements and response to them according to the situation.

iv)Content Provider: Content provider is a SQLite database, which supports the sharing and accessing of data among applications.

2.4    Android Security Policy Enforcement Mechanism

One of the major components of Android mandatory access control is Reference monitor. Which helps in the inter component communication (ICC).  Each component of an application is assign with some permission labels. These labels are used for interaction with the components of other applications. It is possible that a specific component of an application can interact with the component A of other application but can’t interact with the component B of the same application. This happens because of the permission assigns to each component of each application. Whenever a component wants to initiate ICC, the application checks the label of permissions. If the target component’s label is present in that bundle of permissions, ICC establishment is allowed to continue, otherwise denied.

In Android components interact with other components of same or other application through ICC mechanism based upon intents. Intents is mechanism for message passing, that also contains nature of the action to be performed. Intents can be sent to a specific component or can be broadcast to the Android framework. Android framework then passes it to the suitable component. Action strings help in specifying the intents, actually action strings show the type of action to be performed and then Android system take the decision that which component is suitable to perform the required action.

All the permissions are defined in the AndroidManifest.xml file. It also contains metadata related to security policy enforcement. <Permission>  tag specifies the components which can access it. <Intent-Filters>   specify those intents which can be resolved.

2.5    Protection Levels

Android has four permission levels, on the basis of which an application can be install.

i.  Normal: Normal permissions are granted without asking any permission from user.

ii.Dangerous: Dangerous permissions ask for the approval from the user at the time of installation. User has two choices, either grant all permission or deny all. Denying of permissions will stop installation.

iii.Signature: System grants these permissions if the requesting and granting application share the same certificate.

iv. Signature System:  Same as Signature but use for system applications only.

2.6    Limitations

Android permission lacks the modification of permissions. Android policy is very strict. It walks on all or nothing policy. User should allow all permission to allow any installation.

Android do not provide any runtime investigation for the behaviour of application. Once an application installed, so then it can every activity which it wants.

2.7   Mobile Phone Threats

• Proof of concept: Keeping the Bluetooth device on without the knowledge of the user is an example of this threat. It drained device batteries.
• Destructive: Deletion of phone book entries without the knowledge of user is an example of this threat.
• Premeditated spyware:  This category includes location tracking and remote listening.
• Direct payoff:  Sending sms without the permission of the user is a threat include in this category.
• Information scavengers: Checking the address book, passwords and cookies without the permission of the user, lie down in this part.
• Ad-ware: The malware advertisements on cell phones are included in this category.

III.Extending Android Permission Model and Enforcement with User defined runtime constraints

In this paper, author presents a policy enforcement framework for framework for Android that allows users to grant permissions to applications on the basis of their needs. And also to impose constrains on the usage of resources.

3.1   Problem description

Android contain a suit of built in applications like dialler, browser and address book etc. Using the SDK developer can develop their own applications. Applications require some permission which is mentioned in the AndroidMamifest.xml.  These permissions are used for performing sensitive tasks like sms sending, using camera etc. At the time on installation Android asks user to grant permissions to the application to install. User does not have any other choice rather than granting all permissions to the application. Otherwise the application will not get install. Once the permissions are granted then user can not revoke those permissions until user uninstall the specific application.

Granting of a permission to an application results in providing unrestricted access to the resources. Android existing framework does not provide a security check on the usage of resources. For example, if once sms permission is granted to an application. So, that application can start sending sms any time. There is no way to stop it, unless user does not grant all permissions to it.

Four issues: (1) User must grant all permissions to install any application; (2) No way for restricting the granted permissions to an application; (3) As all permissions are based on install time checks, access to resources cannot be restricted based on dynamic constraints and (4) The only way of revoking permissions are to uninstall the application.

3.2   Android Permission Extension Framework

The existing Android application framework does not define specific entry point for execution of applications. There is no main function of applications, as applications are composed of components. So, components can communicate with components of other applications, if they permit them.

Different methods of ApplicationContext class in Android are used to handle the installation of these components. ApplicationContext acts as an interface for intents handling. With the rising of an intent, ApplicationContext two checks, that whether the permissions are associated with the intent and secondly, it checks whether the calling component has been granted with those permissions which are associated with the intent.

The ApplicationContext implements the IActivityManager interface. It uses the concept of binders and parcels, the Inter Process Communication for Android. Binder is the base class for remotable objects, that implements the IBinder interface and

Parcel acts as generic buffer for inter-process messages which are passed with the help of IBinder.

The ApplicationContext creates a parcel with the help of IActivityManager, and decide that calling application has specific permissions. The ActivityManagerService class receives this parcel and extract the PID, UID and the permissions associated with it. After that, send it to the checkPermission method of ActivityManagerService class. Then these arguments are passed to checkComponentPermission, it perform some checks. If the UID is root or system UID then it grants all permissions. For the rest, it will call PackageManagerService which extracts the package name for the pass UID and validate the permissions. If received permission does not match any of those present in the GrantedPermission so, it throws a security exception.

After checking the present security permissions, control is given to AccessManager. For the purpose a hook is placed in the CheckUidpermission of PackageManagerService. As it is the only entry point for permission checking. It throws the UID and the requested permissions to the AccessManager. AccessManager invokes PolicyResolver, it retrieves attached to the related application and using the PolicyEvaluatinonEngine, evaluate it. The policy includes the condition on the basis of which permissions will be denied or granted. EspressionParser retrieves the attribute of application from attribute repository and performs some sort of operations on these attributes.

3.3    Poly Android Installer

Writing policy is complex job for even system administrators. Android targeted at the consumer market and the end users as well. And users cannot complex usage policies. To end this problem the author created Poly. It is an advanced Android application installer. It provides user to specify constraints on the use of an application.

i) Allow: By default Android allows all permissions. This makes the existing Android installer a subset of Poly.

ii) Deny: This approach opposed the current approach of Android, which is all-or-nothing. As this approach give facility to the user to deny any permission by his owns choice. For example if Tom wants download an application and that specific application require some permission, sending sms is one of among those permissions. But Tom wants the application not to send any sms. So Tom will simply tap on the ‘send SMS’ permission and set it to ‘deny’. And still he may be able to install the application and enjoy the rest of facilities provided by that application.

3.4    Constraint Modification at Runtime

One of the limitations of Android security mechanism is the lack of ability of revoking permissions after an application get installs. Uninstalling of an application is the only way to revoke the permissions. Apex allows the user to specify his fine grained constraints at the time of installation through Poly. Once a user come to know that the application is not harmful, and he wants to assign more permissions to it, so Poly will help him in that. For example if a user install an application and grant it some permission and deny the permission of GPS. After some time he realize that this application not harmful and the user wishes to facilitate him with GPS facility as well. For modification the author created a shortcut to the constraint specification activity of Poly in the settings application of Android. (com.android.settings.ManageApplications class). This allows the user to modify constraints he specified at the time of installation. Even after, the application has been installed. And the same rule follows for denying of permissions after installation.

Figure 2: Android Permission Extension (Apex) Framework

IV. Mitigating Android Software Misuse Before It Happens

In this paper, author proposed a framework; know as Kirin to capture security policy that transcends Android applications. Stakeholders’ define some policy invariants, for sack of security. On the base of which, an application will be certified at the time of installation. Mobile phone operating system provides more open APIs for third party applications. That is why the security framework must not only provide per interface permissions, but it should also be capable of supporting “administrative” policies defined by all stakeholders’.

4.1   Contributions

• The author reverse engineer Android’s security model and present it formally.
• Author provides a framework for specifying and enforcing stakeholder security policy.
• Prolog is used for install time installation. Prolog is a common language for security policy evaluation.
• Author use the proposed framework to identify insecure application policy configurations within Android. Such applications can affect voice, SMS and location services.

4.2    Kirin

In this paper a model is proposed, which states that before   system install any downloaded application package, it must first ensure the applications satisfy all security requirements. If any requirements fail to met, the installation will be terminates. This model, of installation ensures the cell phone will remain in its original secure state, without based on user made security decisions.

The policy pre-processor extracts policy from the target applications package, and converts it to Prolog facts. After that it merges it with the existing policy knowledge. The result of the merger represents the security state of the system, if the installation were to proceed. The policy engine after that uses the temporary policy state to evaluate invariants. Policy engine extract invariants from system policy, user policy and applications policy. On the basis of these invariants, policy engine take the decisions. It automatically generates compliance proofs for the target application. If all the invariants satisfied, so installation will continue. If any of the invariant fails to satisfy so the installation will abort.

4.3 System invariants

Invariant 1: “An application must have explicit permission to make an outgoing voice call.”Android uses CALL_PHONE and CALL_PRIVILEGED permissions, to protect the API from making outgoing calls. An application holding the call permission can indirectly provides its API access via its components interface. This invariant makes it sure the no indirect access should be allowed.

Figure 3: Enhanced Installation Logic. New packages cannot be installed unless all policy in variants passes

Invariant   2: “An application holding a dangerous permission must have no unprotected components”

Android framework introduces “dangerous permissions”. Which states that user should allow permissions to applications at time of installation. For example, sensitive tasks like making call and sending SMS permissions are mark as dangerous. So that, any application asks from user before using these services.

Invariant   3: “Only system applications can interface with hardware”. Android framework introduces high level java APIs for interfacing with hard ware. For the sack of flexibility, Android let any application to interact with the APIs, but with proper permissions. This invariant insures only system applications have direct access to APIs.

4.4    User Privacy Invariants

Invariant 4: “Only system applications can process outgoing calls.”[2] Android framework let applications to receive notifications of outgoing calls, including the destination number. To keep the issue of privacy in eye, user may wish that only system applications should receive such notifications.

Invariant 5:  “Applications that can perform audio record must not have network access or pass data to

an application that has network access”. It is quite dangerous for security, if an application record voice and send it on internet.

Invariant 6: “An application with access to Wifi or Network state must also declare network access.”

4.5 Application invariants

Invariant 7:  “An application can only receive SMS notifications from trusted system components.”Any application has the ability to broadcast intent. But some intent can only be broadcast by system applications. This gives the surety that only system applications can send SMS.

Invariant 8: “An application can only receive location updates from trusted system components.”  Some applications take decision on the base of location so, only the system applications have the right to send the location notification.

4.6 Limitations

Kirin is limited to obtain data from application package metadata. Kirin does not provide any dynamic security check. Kirin provides only install time security.

V. ON LIGHTWEIGHT MOBILE PHONE APPLICATION CERTIFICATION

The author proposed Kirin security service for Android, which provides a lightweight certification of application at the time on installation. To certify applications based on security configuration requires to clearly specifying the unwanted properties. For the identification of Kirin security rules, the author took help of security requirements engineering. On other hand a security language design has been defined, to implement Kirin security service within the Android framework.

• Methodology for adding new security requirements and flaws in current Android are defined.
• Practical method of performing lightweight certification of applications at install time is provided.
• Mitigation of malware rules are mentioned.

5.1 Kirin Security Rules

Security requirements engineering is based upon three basics. 1) Operation of a system in normal environment, 2) assets are entities that someone places value upon, 3) security requirements are actually constraints on the functionality of system to protect assets.

5.2 Identifying Security Requirements

Existing security requirements engineering techniques are referred in order to identify dangerous application configuration.

Step 1: Identify Assets: Assets are defined from features of Android platform.  In the form of label permissions, assets are already defined by Google.

Figure 4: Sample Kirin security rules to mitigate malware

All components of system applications are assets basically. Android defines the RECORD_AUDIO permission to protect the audio recorder. Microphone is an asset in this example, as microphone records the voice of user. Permission are define by Android for making phone calls, and observation of phone state as well.

Step 2: Identify Functional Requirement: In this step the author studied the interaction of applications with phone and with third party applications. Assets and functional description plays a vital role in security threats. When an incoming call is receives so, the system broadcasts intent to the PHONE_STATE action string. And also notify the registered application with the PhoneStateListner. In the same way action NEW_OUTGOING_CALL action string is also broadcasted.

Step 3: Determine Assets Security Goals and Threats: Confidentiality, integrity and availability considers being high security goals. Determination of appropriate goals and determination of methods that how functional requirements can be abused with respect to the remaining security goals is important. If a voice call is record and sends on internet, it is against the confidentiality.

Step 4: Develop Asset’s Security Requirement: Next security requirement from the threat descriptions. Security requirements are constrains on functional requirements. Which defines who can exercise functionality.  Observations says that, eavesdropper requires a) notification of incoming or outgoing call, b) the ability to record audio and c) access to Internet. So an application must not have these rights at the once.

Step 5: Determine Security Mechanism Limitations: The goal of this step is to determine dangerous configurations at only install time. Author is limited to information available in an application manifest file. An application must not have permission for processing outgoing calls, record audio and internet permission.

5.3 Single Permission Security Rules

Dangerous permissions of Android may be too dangerous in some production environment. The SET_DEBUB_APP permission allows an application to turn the debugging for another application. The corresponding API is hidden in the most recent SDK. Third party does not have access to hidden APIs but it is not a substitute for security. Rule1 ensures third party applications do not have the SET_DEBUG_APP permission.

5.4 Multiple Permission Security Rules

Voice and location eavesdropping malware need permissions to record audio and access location information. But at same time legitimate applications also use these permissions. So a rule is need as multiple permission. Rule 2 and 3 protect against the voice eavesdropper. Rule 4 and 5 protect from location tracker.  Rule 6 protects from incoming malware SMS. Rule 6 and 7 consider malware interaction with messages. As SMS can be used as a path for malware. And malware owner will not let user let know about SMS, therefore content provider will be is modified just after receiving a SMS.  Rule 7 does not stop SMS sending, but increase the probability that user becomes aware of the activity. Rule8 makes use of the duality of permission labels.

Permissions are not always enough to differentiate between malware and legitimate behaviour. Rule 9 provides example of a rule considering both permission and an action string.  This stops a malware from replacing the default voice call dialler application without the awareness of the user.

VI. SEMANTIC RICH APPLICATION-CENTRI SECURITY IN ANDROID

Android system protects the phone from malicious applications, but with limited infrastructure for applications protection.

Permission assignment policy: Applications have limited ability to control, to which the permissions are granted for accessing their interface.

Figure 5: Policy tree illustrating the example policies required by applications

Interface exposure policy: Androids facility is too rigid for controlling of their interface for other applications.

Interface use policy: Limited means of selecting, at run-time, that which applications interface are accessible.

6.1 Application policies

Permission granting policy is an install time policy. Its subparts have a) Protection level based policy. Normal permissions are granted directly, Dangerous permissions are granted by the wish of user, Signature based permission allows only those permissions to be installed which are signed by the same developer. Signature system is used for system applications only. B) Signature based policy, this is same as signature based, but permissions can be allotted even if application A and B are signed by different developers. c) Applications configuration based policy. This policy keeps on check upon the application version etc.

Interaction policy is runtime policy. Its first three parts are as same as install time policy, but it just checks those permissions at runtime. Additional feature in runtime policy is context based policy. For example if a user do not want to allow GPS permission at specific day or time, or a game should not be start, if the battery is low that 10%.

6.2 Install time policy

Saint install-time policy regulates granting of application on the basis of mentioned permissions. An application define permissions, requested application should hold those permissions in order to communicate with the specific application.

AppPolicy provider takes the decision at time of installation and Saint installer enforce it. AppPolicy maintains record of all install and runtime policies. At the time of installation Android installer retrieves the permissions from the manifest file a) it check the AppPolicy provider for each permission. B) AppPolicy provider consults its policy database, and returns a result by keeping the rule in notice. C) installation will proceed only if the conditions satisfy.

6.2 Runtime Policy Enforcement

For the interaction of softwares components with in Android framework, IPC are used. Caller application sends the IPC and callee receives that IPC. If conditions of both caller and callee satisfy, then IPC continues.

First Saint Madiator retrieves policy file from the application, then send it to Saint AppPolicy provider, the conditions and permissions are checked there. If not satisfied, so the IPC is blocked. Otherwise the IPC is directed towards the current Android permission check and after that communication starts between two applications.

6.3 Administrative Policy

Administrative policy defines the control of user towards policy.  If user is not allowed to change the policy so, he cannot use it in very appropriate way. And if allowed to change then it is a compromise on security. Because user may changes it in wrong way. So author leaves this decision upon operating system. Two flags are defined, SaintOverride flag and Override flag. If both flags are yes, then user can change the policy.

Figure 6: Saint enhances the application installation and interaction of policies.

6.4 Operational Policy

Operational policy consists of three type of conditions.

• Always satisfied
• Satisfiable
• Unsatisfiable

6.5 Saint Architecture

Saint architecture was implemented as modification on Android. For policy enforcement, hooks are placed.

A)    Saint Installer:

It is a modified version of Android installer. Saint installer retrieves all permission from the application package, its version and signature etc. Saint policy is implemented in an XML file with the same name of the package. After parsing the package file, it checks the permissions, if do not satisfy so rejected.

B)    Saint Mediator:

1. Starting an Activity: Saint runtime enforcement consists of four components. Starting new activity, binding components to services, receiving broadcast intents and accessing content provider. For starting an activity, intent is generated, Activity Manager Service open the required program if the name of application is mentioned in the intent. But before starting a security hook will check the policy. If name of application is not mentioned in the intent so the intent will be handed over to Resolver activity. If single match found, so application will be started but a hook is there to check the policy. If multiple applications found for the raised intent, so a menu will be open in front of user, and user will select an application. But before that a hook will check the policy.

2. Receiving intent broadcast: Activity Manager will receive intent. If receiver name is mentioned so, it will receive it but a security hook is there to check the policy. If name of receiver is not mentioned first it will be checked in Dynamic BR list and after that in Static BR list. In both cases hook will be placed to check the policy before starting any activity.

3.Accessomg Content Provider: Any application wants to access content provider, so a hook is placed to check that weather the given application has the permissions to access the content provider .

4. Binding components to services: This allows binding intent to a service. Intent binds to a service either by its name mentioned in the intent or intent containing the action string to which the service is registered.

VII. SUMMARY

In this survey paper four approaches are discussed for the security of Android. Kirin and Lightweight approaches are basically install time approaches. If once an application grant some permissions, so there is no security mechanism through which Kirin or Lightweight keep check on the behaviour of application during runtime. Kirin cannot keep on check on dynamic broadcasts.

Light weight cannot directly utilize these existing techniques because the current techniques are structured to supplement system and software development. Lightweight cannot guarantee fixed number of SMS is sent during in specific period of time.

Comparatively to Kirin and Lightweight, Apex approach seems to be more feasible. As its architecture is simple and the property which give edge to Apex is its runtime policy. Which keep on check on the application behaviour at runtime, and on base of policy do not let an application to do something which permission is not grant to it. Still some problems are there, the installer currently incorporates a small number of constraints. For a larger user community, study of user requirements is required. Secondly it can create problems if user unknowingly grants such permissions to an application which can produce harmful results. This problem can be solved by the conjunction of Kirin with Apex, by analysing the constrains and permissions to verify that security rules are not being violated.

Also developer should mention in the manifest file of an application, that why the specific permission is required for the functionality of the application. For example, requesting GPS permission, the developer should mention that why GPS is needed by the application.

Semantic Rich Application Centric Security in Android is an approach for the security of Android. This approach provides a good security mechanism for install time, runt time and application to application interaction as well. In this approach security hooks are placed in every require place of Android framework for the insurance of security.

Courtesy of Kamran Habib Khan & Mir Nauman Tahir