discretionary access control (DAC). The controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject (unless restrained by mandatory access control)”.

On Linux, discretionary access control allows users to modify the permissions on files that they own, while Linux root account (UID 0) is able to modify the permissions on any file.

For Unix / Linux systems, the term “file” applies to normal files, directories, devices, symbolic links, sockets, and named pipes. An application is nothing more than a normal file with execute permission. It makes no difference whether it is a shell script or a binary file.

The sticky bit on a file tells the kernel to keep the file pointers in the cache. For directories, the sticky bit says that only the owner can delete the file. Android uses the sticky bit on both files and directories.

The Linux kernel always checks the DAC permissions, before checking any extended permissions. Consequently, the Android implementation of Linux permissions always applies.

mandatory access control (MAC).


Android permissions are application permissions, and not just file permissions. By default, every Android application operates in a sandbox. The application cannot access services outside of the sandbox without permission.




Domain in SELinux:

The SELinux Policy is the set of rules that guide the SELinux security engine. It defines types for file objects and domains for processes. It uses roles to limit the domains that can be entered, and has user identities to specify the roles that can be attained. The SELinux policy defines various rules which determine how each domain may access each type.

Domains’ rights are thus expressed with sets of (dis)allowed operations on those types (and, indirectly, on all objects which are labeled with the given type).
SELinux plays an important role during the early stages of system start-up. Because all processes must be labeled with their correct domain. As shown below, SELinux contexts follow the user:role:type:level syntax. A detail explaination about user,role,type and level can be found here

Security contexts and Unix users

By default, a program inherits its domain from the user who started it, but the standard SELinux policies expect many important programs to run in dedicated domains. To achieve this, those executables are labeled with a dedicated type (for example ssh is labeled with ssh_exec_t, and when the program starts, it automatically switches to the ssh_tdomain). This automatic domain transition mechanism makes it possible to grant only the rights required by each program. It is a fundamental principle of SELinux. (Domain transition is checked by SElinux allow rules)

Automatic transitions between domains


SELinux Allow rules: (from web)

policy_module(myapp,1.0.0) 1

# Declarations

type myapp_t; 2
type myapp_exec_t;
domain_entry_file(myapp_t, myapp_exec_t) 3

type myapp_log_t;
logging_log_file(myapp_log_t) 4

type myapp_tmp_t;

# Myapp local policy

allow myapp_t myapp_log_t:file { read_file_perms append_file_perms }; 5

allow myapp_t myapp_tmp_t:file manage_file_perms;
The module must be identified by its name and version number. This directive is required.
If the module introduces new types, it must declare them with directives like this one. Do not hesitate to create as many types as required rather than granting too many useless rights.
Those interfaces define the myapp_t type as a process domain that should be used by any executable labeled with myapp_exec_t. Implicitly, this adds an exec_type attribute on those objects, which in turn allows other modules to grant rights to execute those programs: for instance, the userdomain module allows processes with domains user_t, staff_t, and sysadm_t to execute them. The domains of other confined applications will not have the rights to execute them, unless the rules grant them similar rights (this is the case, for example, of dpkg with its dpkg_t domain).
logging_log_file is an interface provided by the reference policy. It indicates that files labeled with the given type are log files which ought to benefit from the associated rules (for example granting rights to logrotate so that it can manipulate them).
The allow directive is the base directive used to authorize an operation. The first parameter is the process domain which is allowed to execute the operation. The second one defines the object that a process of the former domain can manipulate. This parameter is of the form “type:class“ where type is its SELinux type andclass describes the nature of the object (file, directory, socket, fifo, etc.). Finally, the last parameter describes the permissions (the allowed operations).

Permissions are defined as the set of allowed operations and follow this template: { operation1 operation2 }. However, you can also use macros representing the most useful permissions. The

/usr/share/selinux/default/include/support/obj_perm_sets.spt lists them.

The following web page provides a relatively exhaustive list of object classes, and permissions that can be granted.



The file: /external/sepolicy/seapp_contexts found on the root file system in the android image includes the following content:

isSystemServer=true domain=system_server
user=system domain=system_app type=system_app_data_file
user=bluetooth domain=bluetooth type=bluetooth_data_file
user=nfc domain=nfc type=nfc_data_file
user=radio domain=radio type=radio_data_file
user=shared_relro domain=shared_relro
user=shell domain=shell type=shell_data_file
user=_isolated domain=isolated_app levelFrom=user
user=_app seinfo=platform domain=platform_app type=app_data_file levelFrom=user
user=_app domain=untrusted_app type=app_data_file levelFrom=user

This defines the security settings (outputs) for each process according to some inputs. We can see in this example in the first line:

If its the system server, its domain will be system_server

Or in the last line:

The _app keyword stands for every app which doesn’t have a rule associated to it. So by default, applications domain will be untrusted_app and the files belongs to it label will be app_data_file.

More documentation on the syntax of the file is found inside the file.

Linux Directory Permission:

directory = list of names.

Read bit = If set, you can read this list. So, for example, if you have a directory named poems:

  • You can ls poems and you’ll get a list of items living within (-l won’t reveal any details!).
  • You can use command-line completion i.e. touch poems/so <TAB> poems/somefile.
  • You cannot make poems your working directory (i.e. cd into it).

Write bit = If set, you can modify this list i.e. you can {add,rename,delete} names on it. But! You can actually do it only if the execute bit is set too.

Execute bit = Make this directory your working directory i.e. cd into it. You need this permission if you want to:

  • access (read, write, execute) items living within.
  • modify the list itself i.e. add, rename, delete names on it (of course the write bit must be set on the directory).

Interesting case 1: If you have write + execute permissions on a directory, you can {delete,rename} items living within even if you don’t have write perimission on those items. (use sticky bit to prevent this)

Interesting case 2: If you have execute (but not write) permission on a directory AND you have write permission on a file living within, you cannot delete the file (because it involves removing it from the list). However, you can erase its contents e.g. if it’s a text file you can use vi to open it and delete everything. The file will still be there, but it will be empty.

A file can only be deleted if its directory‘s permissions allow Write.

Denial Log:
– Captures SE for Android denials in Enforcement mode on the device and uploads
them to a Samsung Server.

– These denial logs are stored on the device at:
/data/misc/audit/audit.log and audit.old).