SElinux Basic Configuration Basic Syntax __linux

This really is the network good many articles, I also many are everywhere reprint summary, then is oneself again to add and modified some. http://blog.csdn.net/myarrow/article/details/10105961, this is very detailed.

KK
Google has enabled SELinux by default and will print SELinux audit exceptions in kernel log or Android log (L), the corresponding keyword is: "avc:denied" or "avc:denied" KK version, Goog Le only limited enabled SELinux, that is, only for netd, Installd, Zygote, Vold and their direct fork of child process using enforcing mode, but does not include zygote fork of the ordinary app.

L M N
L version above, the full opening of Google SELinux, almost all of the process to make enforcing mode, resulting in a lot of KK on the normal use of the interface will be reported permissions denied

Android, SELinux, avc:denied, audit

Configuration directory

Android 4.0 temporarily without
The SELinux permission configuration of MTK is in Mediatek/custom/common/sepolicy

Android 5.0
The SELinux permission configuration of the system is in the anroid/external/sepolicy/directory
Qualcomm's SELinux permission configuration is in the anroid/device/qcom/sepolicy/
The SELinux permission configuration of MTK is in Android/device/mediatek/common/sepolicy

Android 6.0
The SELinux permission configuration of the system is in the anroid/external/sepolicy/directory
Qualcomm's SELinux permission configuration is in the anroid/device/qcom/sepolicy/directory, if there are many versions of the generic version of the common directory to add.
The SELinux permission configuration of MTK is in Android/device/mediatek/common/sepolicy

Basic concepts of SELinux resource access
Object category and license
http://blog.csdn.net/myarrow/article/details/10073853

SELinux uses type coercion to improve forced access control. All subjects (program processes) have access to objects (file/socket and other resources) with a TE rule to permit. When a program accesses a resource,
The system searches all the TE rule sets and processes them according to the results. This rule set is described by Access vector Rules (AV, Access vector).

The kernel exposes the access-allowed resource permissions to the outside, and the TE describes what access the subject has. The SELinux defines 30 different object classes:

There are a number of operational licenses for file

IOCTL Read write create GetAttr setattr lock relablefrom relableto append unlink link rename execute swapon quotaon mounto N Execute_no_trans entrypoint

Second, open SELinux permission limit

2.1 First must first turn on the SELinux function, Google provides the option to open the switch
The following variables are defined in the BOARDCONFIG.MK:

Board_sepolicy_dirs + + Build/target/board/generic/sepolicy

There are many te files below the corresponding path to describe the process's access to resources.

The Android system itself defines a directory that is
In the android.mk under the Anroid/external/sepolicy

Qualcomm Platform is in (we develop also here added)
In the android.mk under the anroid/device/qcom/sepolicy/

For example, a board_sepolicy_dirs configuration under a qcom platform

# Board specific SELinux policy variable definitions
($ (call ifeq), true)
is-vendor-board-platform,qcom Sepolicy_dirs: = \
      $ (board_sepolicy_dirs) \
      device/qcom/sepolicy \
      device/qcom/sepolicy/common \
      Device/qcom/sepolicy/test \
      device/qcom/sepolicy/$ (target_board_platform)
endif

# Add yourself
board_ Sepolicy_union: = \
       xxxxxxx.te \
       xxxxxxx.te \

2.2 Configuration file Overview

  External/sepolicy/attributes-> all defined attributes are in this file
  external/sepolicy/access_vectors-> Corresponds to a command that each class can be allowed to execute 
  external/sepolicy/roles-> Android only defines a role, named R, which associates 
  R with attribute domain External/sepolicy/users-> is actually associating user with roles, setting the user's security level, S0 the lowest level is the default level, and Mls_systemhigh is the highest level
  external/ Sepolicy/security_classes-> refers to the class in the command above, which the individual thinks is the module of the operation that the program or system might use during the Android operation 
  external/ Sepolicy/te_macros-> system-defined macros are all in Te_macros file 
  external/sepolicy/*.te-> Some of the configured files that contain various running rules

2.3 SELinux has two modes of operation

"Permissive": all operations are allowed (that is, no Mac), but log is logged if there is a violation of permissions
"Enforcing": all operations will be checked for permissions

iii. te te:type Enforcement) policy, basic definition

The configuration above is configured with the. te file, which is our basic syntax.

3.1 Definition Types

In te, everything is abstracted into a type. Processes, which are abstracted into types, resources, and abstract into types. property, which is a collection of types. Therefore, the smallest unit in the Te rule is the type.

Defines  the type name [alias alias set] [, property set];
 Type XXXXX;
 Tyep  alias{AA, BB, cc}     XX,  YY;      Properties separated by commas

3.2 Using Typealias to declare aliases

 # These two statements are equivalent to   
type mozilla_t, domain;   
Typealias mozilla_t alias netscape_t;   

#下面这一条语句   
type mozilla_t alias netscape_t, domain; 

3.2 declaring Properties
(the Android attribute definition file should be defined as basically all properties in the Android/external/sepolicy/attributes file)

 Attribute  XXXX;
 attribute domain;


part of the system definition

# All types used for processes.
attribute domain;

# All types used for files, can exist on a labeled FS.
# do no use for pseudo file types.
attribute File_type;

# All types used for domain entry points.
attribute Exec_type;

# All types used for/data files.
attribute Data_file_type;

# All domains used for apps.
attribute AppDomain;

# All domains used to apps with network access.
Attribute Netdomain;

3.3 types are associated with attributes

Here I use the code in the system to show that the address is/android/external/sepolicy/file.te

#/data/data Subdirectories-app sandboxes
 type App_data_file, File_type, Data_file_type;

 #/data/data subdirectory for System UID apps.
 Type System_app_data_file, File_type, Data_file_type, Mlstrustedobject;

 # compatibility with type name used in Android 4.3 and 4.4.
 Typealias app_data_file alias Platform_app_data_file;
 Typealias App_data_file alias Download_file;

You can also use Typeattribute for "property" associations

  (1)
  Type keystore, domain;
  Type keystore_exec, Exec_type, File_type;
  Init_daemon_domain (keystore)
  ////////////////////////////////////////
  Typeattribute keystore Mlstrustedsubject;


  (2)
  Type httpd_user_content_t;
  typeattribute httpd_user_content_t File_type, httpdcontent;  

Type and Attribute Association
the access vector (AV) rule AV is used to describe the subject's access permission to the object. There are usually four types of AV rules:

allow: An operation that allows a subject to perform a permission on an object.
Neverallow: Indicates that the subject is not allowed to perform actions on the object .
Auditallow: Represents the Allow operation and records access decision information.
Dontaudit: Does not record the decision information that violates the rule, the cut violates the rule does not affect the operation.

4.1 Allow

  Allow user_t Bin_t:file execute;  

  Allow user_t {bin_t sbin_t}: File execute;

  Allow {user_t domain} {bin_t file_type sbin_t}: File {execute  read};

  Allow user_t bin_t: {file dir} {read GetAttr}; 

* For wildcard characters, all operations

Allow user_t bin_t: {file dir} *;   

The complement operator (~), that is, in addition to the listed licenses, other licenses include
This rule allows a process with user_t in any security context to have all write SetAttr IOCTL access to a normal file of type bin_t in any security context.

Allow user_t bin_t:file ~{write setattr ioctl}; 

4.2 Neverallow

Allow domain {exec_type-sbin_t}: file execute;  
  #等同于  
  

    Neverallow * Domain:dir ~{read getattr};  

This rule states that no allow can grant any type of access to a directory of the type with the domain attribute, except for read and GetAttr access (that is, reading access), where the wildcard character of this rule means all types,
in real policy, Rules like this are common, and they are used to block the proper access to the/proc/directory.
we see from the previous example that wildcards are needed in the Source type list, because we want to point to any type or all types, including those that have not yet been created, and use wildcards to prevent us from making mistakes in the future.

Another common Neverallow rule is:
This neverallow rule enhances the domain attribute, which indicates that the process cannot be converted to a type with no domain attribute, which makes it impossible to create a valid policy for a process that has no doamin property for a type.

Neverallow Domain ~domain:process transition;  

4.3 auditallow

SELinux has a large number of tools to log information, or to audit, access information that attempts to be allowed or denied by policy. Audit messages, commonly called "AVC messages," provide detailed information about access attempts, including whether to allow or deny the security context of the source and destination.
And some other access attempts involve resource information. The AVC message, like other kernel messages, is stored in a log file in the/var/log directory, which is an indispensable tool for policy development, System management, and system monitoring. Here, we check which access attempt generated the audit message.

By default, SELinux does not record any allowed access checks, and only the denied access checks are logged. It is not surprising that, on most systems, tens of thousands of accesses are allowed per second, and only a small number of them are rejected, and the allowed access is usually expected, usually without auditing, and denied access is usually (but not always) unintended. Auditing them makes it easier for administrators to discover policy bugs and possible intrusion attempts. The policy language allows us to cancel these default, expected reject audit messages, and to log the allowed access attempt audit messages instead.

Dontaudit httpd_t Etc_t:dir Search;
SELinux provides two AV rules that allow us to control which access attempts are audited: Dontaudit and Auditallow. Using these two rules we can change the default audit type, the most commonly used is the Dontaudit rule, which indicates which access attempt is rejected without auditing, overwriting the SELinux default auditing of all denied access attempts.

Remember, the audit (audit) rules let us override the default audit settings, allow rules indicate what access is allowed, Auditallow rules do not allow access, and it only approves permitted licenses.
Note: Auditing is not the same in licensing and enforcement mode. When you run in force mode, you audit each time you allow or deny it, and you should limit the audit frequency in the policy (you can use the AUDITCTL implementation). In licensing mode, only the first access attempt is recorded until the next policy load, or fixed to mandatory mode, which is typically used for development, which can reduce the size of the log file.

4.4 Dontaudit

v. Types of rules

A type rule specifies its default type when it creates an object or when it is re marked while it is running, providing only a new default type tag. Two types of rules are defined in the policy language:

type_transition
The default type is specified when the markup behavior occurs during a domain conversion and when the object is created.
Type_change
Specifies its default type when using a SELinux application to execute a tag.
We call these rules "type rules" because they are similar to AV rules except that the end of a rule is a type name and not a license set.

5.1 Common Type rule Syntax
As with AV rules, each type rule has a different purpose and semantics, but their syntax is generic, and each type rule has the following five elements:
• Rule name: Type_transition or Type_change

  • Source Type: Create or own a process type 

  • Target type: Object type of object containing new or re-tagged objects • 

  object Category: category of newly created or re-tagged objects 

  • Default type: A single default type

  rule syntax for newly created or re-tagged objects
  • Rule name Type set type set: Class set  single default type;
  1 Rule name: The name of the type rule, valid rule names are Type_transition,type_change and Type_member.
  2 Type set: One or more types or attributes. The source and destination types in a rule have their own set of types, and multiple types and properties are delimited by spaces, enclosed in curly braces, such as {bin_t sbin_t}, which can be placed in front of the type name (-) to exclude them, such as {exec_type–sbin_t}.

  3 category set: One or more object classes, multiple object classes must be enclosed in curly braces and separated by spaces, such as {file Lnk_file}.
  4) Default type: A single default type specified for the newly created or tagged object class, where properties and multiple types cannot be used.
  5 All type rules are valid in a single policy, the underlying load module, the non-underlying load module and the conditional statement.
 type rule syntax is mostly similar to AV rules, but there are some different places, first of all, there is no license in the type rule, unlike the AV rule, the type rule does not specify access rights or audits, and therefore requires permission; The
 second difference is that the object class does not have an associated target type, instead, The object category refers to the object that will be marked by the default type.

The simplest type rule consists of a source default type, a target default type, and an object class, as follows:

Type_transition user_t passwd_exec_t:process passwd_t;  

It points out that when a process with a type of user_t executes a file of type passwd_exec_t, the process type will attempt to convert, unless there are other requests, the default is to change to passwd_t, when the object class of the declaration is a process (processes),
Implied that the target type is associated with the file object class, the declared object class (process) is associated with the source and the default type, and this hidden Association is easily overlooked, even if you become a strategic authoring expert.

5.2 Type conversion rules type_transition

We use the Type_transition rule to specify the default type, and there are currently two Type_transiton rules for the format:

1 support for Default domain conversion events

2 supports object conversion, which allows us to specify the default object tag

These two forms of type_transition rules help enhance the security of selinux transparent transitions to Linux users, and by default in SELinux, newly created object inheritance includes the type of object (such as a directory).
The process inherits the type of the parent process, which is useful for type_transition rules that allow us to override these default types, for example: to ensure that a password program creates a file in the/tmp/directory with a different and normal user type.

The type_transition rule does not have allow access, it only provides a new default type token, and for a successful type conversion, a set of associated allow rules is required to allow the process type to create objects and tag objects.
In addition, the default tag is specified in the Type_transition rule, and it works only if the creation process does not explicitly overwrite the default markup behavior.

5.2.1 Default Domain Transformations (process type conversion processes)
Let's take a detailed look at the field transformation format in this rule, and when executing a file, the domain transformation changes the type of the process, as in the following rule:

Type_transition init_t apache_exec_t:process apache_t;  

This rule indicates that the process type will be converted to apache_t when the type-init_t process executes a file of type apache_exec_t. Object class process only indicates that this is the format of a domain conversion rule.
The following illustration shows a domain transformation, in fact, the domain transformation simply changes the existing type of the process, rather than creating a new process, because creating a new process in the Linux transformation begins by calling the fork () system call to replicate an existing process, if the process type is changed on the fork, It allows the domain to execute arbitrary code in the new domain, which is more secure when a domain transformation occurs when a new program is executed through a EXECVE () system call.

As mentioned earlier, type conversions occur only if the policy permits relevant access, and the domain conversion succeeds, and the policy must allow the following three access rights:
      Execute: Source Type (init_t) has execute permission on the destination type (apache_exec_t) file
      Transition: The source domain (init_t) must have a transition license entrypoint for the default type (apache_t)
      : The new (default) type (apache_t) to the target type (apache_exec _t) file must have Entryponit permission

at the same time, the above domain conversion rules must have the following allow rules to succeed:

This field transforms the rule.   
Type_transition init_t apache_exec_t:process apache_t;   

At least the following three allow rules are required to successfully   
allow init_t apache_exec_t:file execute;   
Allow init_t apache_t:process transition;   
Allow apache_t apache_exec_t:file entrypoint;  

In practice, in addition to these minimum allow rules, we might want to add some additional rules, such as the common default type that sends an exit signal to the source type (that is, the SIGCHLD license), inherits the file descriptor, and communicates using the pipeline.
The most critical concept of domain transformation is the clear definition of the entry point, where a file of type apache_exec_t has entrypoint permissions for the new default type apache_t. The entry point file allows us to strictly control which program can be executed in which domain (which is considered to be the security attribute of type coercion).
We know that the program can enter a given domain only if the type of the executable file of the program has entrypoint permission for the domain, so we can know and control which program has the privilege.

5.2.2 Default Object conversion (file
Object conversion rules specify a default type for the newly created object, in fact, we usually use this type_transition rule on the object (such as File,dir,lnk_file, etc.) related to the file system, and the same as the domain transformation, These rules only raise a default object tag attempt,
And only if the policy allows access, the attempt will succeed.
The object conversion rules are marked by the object category, such as:

Type_transition passwd_t tmp_t:file passwd_tmp_t;  

This type_transition rule states that when a process of type passwd_t creates a normal file (the file object class) under a directory of type tmp_t, by default, if the policy allows,
The newly created file type should be passwd_tmp_t, noting that the object class target type is not tmp_t but the default type passwd_tmp_t, in this case, tmp_t implicitly associates the Dir object class because it is the only object class that can hold the file, and likewise, As before, the policy must allow access to the default tags, and for the previous example, access to a directory of type tmp_t needs to include add_name,write and search, and read and write access to files of type passwd_tmp_t.
This example is typical of a security issue that addresses the sharing and inheritance of multiple applications under the same directory, such as in a temporary directory where object conversion rules are useful for objects that are created at run time.

In some cases, object conversion rules cannot be used, and when a process needs to create multiple different types of objects in the same object container, a type_transition rule is not enough, for example: Suppose a process creates two UNIX domain sockets in the/tmp/directory, These sockets will be used to communicate with other domains, if we want to give each sock file different types, the object conversion rules will not be satisfied, then need two rules, they have the same source type, target type and object class, but the default type is different, but this will produce errors at compile time, The solution to this problem is to create sock files at installation time, mark them explicitly, place sock files in directories of different directory types, or make the process explicitly request a type when it is created.

5.3 Type Change rule type_change
We use the Type_change rule to specify the default type for the application that uses the SELinux attribute, and similar to the type_transition rule, the Type_change rule specifies the default tag but does not allow access.

the difference from the type_transition rule is as follows:
The impact of the Type_change rule does not take effect in the kernel, but relies on user-space applications, such as login or sshd.

In order to redefine the object on a strategic basis, such as the following rule:

Type_change sysadm_t tty_device_t:chr_file sysadm_tty_device_t;  

This type_change rule indicates that the sysadm_tty_device_t type should be used when sysadm_t a character file of type tty_device_t on behalf of the name.
This rule is the most common example of using the Type_change rule, which marks the terminal device when the user logs on, and the login program queries the SELinux module's policies through a kernel interface, passing types sysadm_t and tty_device_t,
Receives the sysadm_tty_device_t type as a type of re tag, which allows the login process to mark the TTY device in the name of the user during a new login session, encapsulating the special type into the policy without being hard-coded into the application.
we may rarely use type_change rules, because they are typically used only by core operating system services.

Summary
• Type is the primary basis for access control in SELinux. They play the role of access control attributes for all objects (processes, files, directories, sockets, etc.), and types use types statement declarations.

• Attributes are type groups. In most policies, attributes can be used where the type is available. Before using attributes, we must declare that in the types declaration statement, we can add the type to the property, or use the Typeattribute statement to do the same.

 • Alias is another name for the type, primarily for backward compatibility when renaming a type, declaring an alias when declaring a type, or using the Typealias statement declaration alone.

 • There are four AV rules, and their syntax is the same: Allow,neverallow,auditallow and Dontaudit.

 • We use the Allow rule to indicate what object type is required to access a domain type, and we specify access according to the object class and license.

By default, access is allowed without an audit message, but when access is denied. We use the Dontaudit rule to indicate that a denied access does not produce an audit message, and we use the Auditallow rule to indicate that the allowed access generates an audit message.

AV rules (such as allow) are cumulative, and for a given source type, the target type and the object class key, at runtime, the allowed and audited access is the sum of all the rules that reference the key.

 • We use the Neverallow rule to point out fixed attributes that will never be allowed by the Allow rule, and if a allow rule violates this principle, the CheckPolicy compiler generates an error at compile time.

 • There are two types of rules, and their syntax is the same: Type_transition and Type_change. Type rules do not have allow access, instead they specify the default tagging policy that object creation and marking events want.

 • We use the type_transition rule to mark it (object conversion) when creating a new object, or to change the type of the process (domain conversion) when executing a new application.

 • We use the Type_change rule to specify the default type for the RE tag object, which is used for selinux sensitive programs such as login and sshd.

 • Policy Analysis tools are a valuable tool for Apol understanding and analyzing complex selinux strategies.