SEAndroid - SELinux for Android [Part Two] : Introduction to SELinux Policy Language
Since Linux has
multiple distributions, the SELinux implementations
of each are slightly different. Google has made certain
modifications to get SEAndroid working on the Android platform.
This tutorial will
introduce how Android implements SELinux support.
However, before we
delve into the core implementations and other details. Let us take some time to
understand some basics.
I am using
android-6.0.1_r81 branch from the google’s android source code repository [repo
init -u https://android.googlesource.com/platform/manifest -b
android-6.0.1_r81] for all my explanations.
SELinux’s
[SEAndroid’s] philosophy is very simple.
Any process which
wants to do anything in an SELinux enabled system must
first have permissions in the security policy configuration file.
If there is no
permission in the security policy configuration file the process does not have
this permission it will not be allowed and AVC denial will be reported by the
system.
Let us take an example
from external/sepolicy/netd.te
Explanation:
The following SELinux statement indicates that
processes in the netd domain can be allowed to write a file of type proc_net.
Note that the security policy file in
SELinux has its own set of syntax formats. We will describe it in detail below.
If you do not have the above
statement in netd.te netd will not be able to write to /
proc directory even if netd had root privileges.
We can clearly see how important is understanding the security policy
files and language to be able to.
· Understand
existing security policy.
· Write
a security policy file that meets specific needs of the process.
Introduction
to SELinux Policy Language
In SELinux, everything is given a security attribute.The official name
is Security Context.
Security Context (SContext ) is a string consisting of three
parts.
For example SEAndroid , the
process SContext can be obtained by the ps -Z view
command. The output of the command will have the security context of all the
processes running currently.
Example:
$ ps –z
u:r:netd:s0
root 116
1 /system/bin/netd
From the above output we see in the leftmost
column [u:r:netd:s0] is the processes Security Context.
The process in this case is /system/bin/netd. When we analyze the sContext of the
process we see the following values of u:r:netd:s0 where.
i.
u represents user . SEAndroid represents
a SELinux user.
ii.
r represents role: Mainly used
in Role based Access Control [RBAC]. Simply put a u can belong to
more than one role. Different roles have different
permissions. We will discuss this later.
iii.
netd indicates that the domain to which
the process belongs is netd . The basic management idea
of a MAC is actually so-called Type Enforcement Accesc
Control (referred to as TEAC , generally expressed
as TE ).For a
process, Type is Domain .
- For example, netd domain we can specify
what permissions are required [Example: allow rules].
· S0 is related to the Multi-Level Security ( MLS )
mechanism designed for the military and education industries and it is out
of the scope of this tutorial.
Similarly if we have to see the security context of files we can
do the following.
$ cd /system/bin
$ ls –Z
Output:
-rwxr-xr-x root
shell
u:object_r:netd_exec:s0 netd.
In the above output the second-to-last column shows SContext
[u:object_r:netd_exec:s0] information for several files and
directories.
The information is u:object_r:netd_exec:s0 .
Similar to the above.
i.
u: This is also the
meaning of user . It represents the SELinux user
that created this file.
ii.
Object_r: The file is dead, it can't play a role, so
in SELinux , dead objects are
represented by object_r to their role.
iii.
netd_exec: Type of dead thing , and
the domain of the process is actually a meaning.
iv.
s0: MLS level.
Just
to re-iterate [Sorry for repeating but we really need to byheart this one].
According to the SELinux specification, the
complete SContext string is composed of the following:
user:role:type[:range]
The core
of SContext is actually the first three parts: user:role:type.
The basic management
unit of MAC basic
TEAC (Type Enforcement Accesc Control (TE)).
Let's take a look
at TE.
Introduction to TE
From our earlier examples we have already seen TE
in action. We saw an example of the TE 's allow statement. Let us revisit it once again
and in more details now.
# For /proc/sys/net/ipv[46]/route/flush.
allow netd proc_net:file write;
The components of this statement is:
i.
allow : TE 's allow statement,
indicating authorization. In addition to allow ,
there are also allowaudit , dontaudit , neverallow, and
many others.
ii.
netd : source type . Also
called subject domain.
iii.
proc_net : target type . It
represents the type corresponding to the file that follows.
a.
type
proc_net, fs_type;
b.
type
proc, fs_type;
iv.
file: represents Object Class. It
represents a class of things that can be administered to a subject. For
example, file , dir , socket etc.
v.
write: The operation defined in
this class Object Class .
According to the SELinux specification, a sample allow- related
statement format is.
rule_name source_type target_type : class perm_set;
Let us look directly at a few more examples to fortify our
understanding.
The final conf file with all the required policies are in policy.conf [out/target/product/$(TARGET_PRODUCT)/obj/ETC/sepolicy_intermediates].
1. allow zygote init:process sigchld;
Explanation:
Allow the processes in the zygote domain
to send sigchld signals to the init type process (Object Class is process).
2. allow zygote appdomain:dir { getattr
search };
Explanation:
Allow the process in the zygote domain
to search or getattr the directory of type appdomain. Note that multiple
perm_set in the {}.
3. neverallow { appdomain -bluetooth }
self:capability *;
Explanation:
If there is no declaration, there is no
permission by default. That neverallow statement does not need
to exist.
Because "no authority" is not
required to declared.
For more details please go through the
official documentation of SELinux.
Let us look at the object
class and perm set involved in one of the above allow statements.
1. Object class and Perm Set
It is difficult for the Object class to
clearly explain how it is defined in the language. Therefore, It directly tells
everyone what are the common Object classes. See the following SEPolicy example:
The above example shows
the definition of Object Class in SEAndroid, where
· The Object Class needs to
be declared by the class statement. These declarations
are placed in a file called security_class.
It is said that when the kernel
is compiled, the corresponding header file is generated based on
the security_class file.
Let's look at the Perm
set . Perm set refers to an operation owned
by some Object class . For the object
class file, its own Perm
set includes read, write, open, create,
execute, and so on.
Like the Object
class, the Perm set supported by SELinux or SEAndroid also
needs to be declared. Let's look at the following example.
Note:
Object class and Perm
set specific content (SELinux in fact, called Access the
Vector ) and both Linuxsystem / Android system are closely
related. Therefore, from the perspective of the knowledge chain,
the basics of Linux programming are very important.
2. type, attribute, and allow
Now let's look at the definition of type. There
are three main types of commands, as shown in the following example:
The complete format of the #type command is
“type type_id [alias alias_id,] [attribute_id]”
# where the content in square brackets is optional. Alias
specifies an alias for type, which can specify multiple aliases.
In SELinux,
setting or assigning SContext to a process or file is called Security
Labeling, and local languages are called tags.
After the Android system is booted ( similar
to other Linux distributions), the init process passes
a compiled security policy file to the kernel to initialize the SELinux- related
modules in the kernel (provisionally using the Linux
Security Module: LSM to represent it), then through LSM it
can tag related objects based on the information.
The information needed
for LSM initialization and the SContext information are
saved in two special files. Take Android as an example.
i.
Initial_sids :
defines the related information when the LSM is initialize.
ii.
SID is a
concept in SELinux and it is called Security
Identifier.
iii.
SID is
similar to SContext used by the kernel [SContext is string and strcmp
could be costly in kernel for each operation].
iv.
SELinux uses SID to
match a SContext .
v.
Initial_sid_context.
Look at the contents of these two files:
3. File System label
In SELinux, there are special statements for File-related
entities.
Let us look directly at the following.
The above contents are very simple and self-explanatory.
We have now been able to acquire some basic understanding of SELinux Policy language by now.
In the next tutorials, we will have a look at
the detailed analysis of SEAndroid from a control/data flow perspective.
Comments
Post a Comment