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.
Appendix.
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.

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_t
domain). 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)######################################## # # Declarations # type myapp_t;
type myapp_exec_t; domain_type(myapp_t) domain_entry_file(myapp_t, myapp_exec_t)
type myapp_log_t; logging_log_file(myapp_log_t)
type myapp_tmp_t; files_tmp_file(myapp_tmp_t) ######################################## # # Myapp local policy # allow myapp_t myapp_log_t:file { read_file_perms append_file_perms };
allow myapp_t myapp_tmp_t:file manage_file_perms; files_tmp_filetrans(myapp_t,myapp_tmp_t,file)
SEAndroid
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).
Links:
http://selinuxproject.org/page/NB_SEforAndroid_1
http://selinuxproject.org/page/NB_SEforAndroid_2
http://blog.csdn.net/luoshengyang/article/details/37613135
http://blog.csdn.net/innost/article/details/19299937
http://blog.csdn.net/innost/article/details/19641487