中国成语和谚语 Chinese Idioms & Proverbs

v1 2017/4/23

Here is the Google doc for comments, corrections, request, or whatever.

形容词 (adj.)

并行不悖not mutually exclusive
泾渭分明clear cut
井底之蛙people with narrow/limited perspective/experience
刻舟求剑not flexible to adapter to a changing situation
柳暗花明a glimmer of hope at one's darkest hour,
理所當然take it for granted
盲人摸象we all only have partial understanding of something
前後矛盾inconsistent; contradictory
水到渠成effortless; something comes naturally
适得其反backfire;have an opposite/undesirable effect to what was intended
深入浅出explaining in simple terms despite being immensely knowledgeable
三心二意without consistency; hesitant and wavering
拖泥帶水do something in a long-drawn or slovenly manner; indecisive
唾手可得low hanging fruit
审美疲劳can't appreciate the beauty since you're now accustomed to it
玩火自焚he who plays with fire will get burnt
有意無意seemingly unintentional but actually purposeful
冰山一角tip of the iceberg
百感交集lots of emotions crowd into the heart
板上钉钉fixed or decided
彻头彻尾thoroughly, right down the line
陈词滥调clichés; platitudes
脣亡齒寒in a same boat
差強人意barely acceptable, so so
得不償失the loss outweighs the gain
别有用心ulterior motive
海底摸针find a needle in a haystack
逆水行舟to go against the tide
半推半就half-declining and half-accepting attitude
同病相憐in the same boat
贪多嚼不烂bite off more than one can chew
彼一时,此一时time change
此地无银三百两a clumsy denial (resulting in self-exposure)
曾经沧海难为水been there, done that
打落牙齿和血吞silently endure all manner of insults and abuse


口蜜腹劍sweet words but wicked heart
百口莫辯unable to give a convincing explanation in self-defense
反唇相讥rebut with sarcastic remarks,rather than submit to one's criticism
火上加油add fuel on fire
混淆视听to obscure the facts
冷嘲熱諷cynical,burning satire and freezing irony, sarcastic ridicule,
明知故問ask intentionally a question
強詞奪理use lame arguments and perverted logic
人云亦云to follow the herd
闪烁其词to speak evasively; to hedge
信口雌黄bullshit, to utter nonsense,talk nonsense
相提并论equate a with b; comparable;
文過飾非to cover up one's fault by clever use of words in writing
低声下气meek and timid; submissive
語無倫次to speak incoherently,confused and incomprehensible speech
添油加醋exaggerate or adding false information to draw attention
開門見山get right to the point
自以為是to consider oneself in the right/infallible; self-righteous
自取其辱to bring humiliation on oneself
曲意逢迎curry favour
上谄下骄flatter towards superiors and arrogant towards inferiors
怒不可遏can't contain/restrain one's anger/fury
憤世嫉俗cynical; embittered
顺其自然just sit and relax
自知之明the wisdom of knowing himself
温良恭俭让temperate, kind, courteous, restrained and magnanimous
趁火打劫to take advantage of chaos for one's own profit
断章取义to take something out of context
抛砖引玉toss out a half-baked idea; 2 cents
投机倒把to engage in speculation and profiteering
袖手旁观see it fail
喧宾夺主steal the thunder
以牙還牙to take an eye for an eye
耀武扬威to brag of one's military prowess
置之不理to ignore; to brush aside; to pay no heed to
幸灾乐祸Pleasure derived by someone from others' misfortune.
多此一举an extraneous move
得寸进尺gain an inch and ask for a yard
授人以柄to relinquish one's power or authority to someone else
半途而废give up halfway
暴跳如雷infuriated; enraged; to be furious; to be hopping mad
背道而馳run in opposite directions
捕风捉影make groundless accusations
眼不見為淨turn a blind eye to something
自扫门前雪only worry about one's own affairs
量入為出make ends meet
入乡随俗when in Rome, do as the Romans
趁热打铁strike while the iron is hot
亡羊补牢Better later than never
察言观色to read a person
身體力行practice what one preaches
以身作則to set an example
疏財仗義willing to disperse money in order to uphold justice


话不投机半句多when not congenial, even half a sentence is too much.
患难见真情A friend in need is a friend indeed.
百闻不如一见seeing is believing
家和万事兴harmony in the family leads to prosperity in all undertakings
聪明反被聪明误Clever people may be victims of their own cleverness
覆水难收don't cry over spilt milk.
己立立人,己達達人live and let live
鸟尽弓藏to cast somebody or something aside when the purpose has been served
弱肉强食law of the jungle
人非聖賢Nobody's perfect.
人而無信,不知其可A man without honesty is capable of nothing
如人飲水I know what I have experienced than anybody else
授人以魚不如授人以漁give a man a fish < teach a man to fish
习惯成自然habit makes a second nature.
三思而后行look before you leap
三人成虎repeat it by three individuals, people with believe it
塞翁失馬,焉知非福A setback may turn out to be a blessing in disguise.
英雄所見略同Great minds think alike
有奶便是娘One obeys those who give him money or power.
與人方便,自己方便make things easy for others, they will make things easy for you.
有其父必有其子like father, like son
这山望着那山高the grass is always greener on the other side of the fence
知耻近乎勇Having a sense of shame is a form of bravery
哀莫大於心死Despair is the greatest sorrow.

source & copyrights

Content is available under CC BY-SA 3.0

Android Security: A walk-through of SELinux


In DAC, each process has a owner and belong to one or several groups, and each resource will be assigned different access permission for its owner and group members. It is useful and simple. The problem is once a program gain root privileged, it can do anything. It has only three permissions which you can control, which is very coarse.
SELinux is to fix that.
It is much fine grained. It has lots of permissions defined for different type of resources. It is based on the principle of default denial. We need to write rules explicitly state what a process, or a type of process (called domain in selinux), are allowed to do. That means even root processes are contained. A malicious process belongs to no domain actually end up can do nothing at all. This is a great enhancement to the DAC based security module, and hence the name Security-Enhanced Linux, aka SELinux.
In this article, we'll have a walk-through of various components of SELinux on Android. We will take a top-down approach. The reason is SELinux has lots of concepts to understand, and files to manipulate, so quite likely, you will won't get the big picture if I were to start with the details first.
However, it is also possible that this approach will create more confusing. But let's try anyway.

How SElinux works

The core idea of SELinux is to label every resources and processes, and on the base of default denial, to craft explicit rules granting a process certain permissions to access the resources.
Let's break it down.
  1. Define resource types, and label the resources
  2. Define process domains, and label the processes
  3. Write rules that grant a process the permissions
  4. Rules in action.

Define resource types, and label the resources

Define resource types

Use the type keyword and declare it in a .te file. The suffix te stands for Type Enforcement and no surprise, type are defined in this file.
Specifically, in Android:
  • Types for (normal) files are defined in the /system/sepolicy/file.te.
  • Types for devices files are defined in the /system/sepolicy/device.te.
  • Types for executables files are defined in individual domain files, e.g /system/sepolicy/mediaserver.te for mediasever domain.
Here is the example for each type of te files:
Code snippet of file.te:
# Filesystem types
type labeledfs, fs_type;
type pipefs, fs_type;
type sockfs, fs_type;
type rootfs, fs_type;

# proc, sysfs, or other nodes that permit configuration of kernel
type proc_bluetooth_writable, fs_type;
type proc_cpuinfo, fs_type;
type proc_iomem, fs_type;
type proc_meminfo, fs_type;
type proc_net, fs_type;

type adb_data_file, file_type, data_file_type;
Code snippet of device.te:
type audio_device, dev_type;
type binder_device, dev_type, mlstrustedobject;
type block_device, dev_type;
type camera_device, dev_type;
Code snippet of mediaserver.te, an example domain te file. (Domain te files also include other important things but at this moment, we'll focus on the type definition only.)
type mediaserver_exec, exec_type, file_type;
A few takeaways:
  • It is really a very fine grained type system. Take a look at those different types of proc_xxx. Because of this fine grained labelling, we can write accurate rules that will only allow a process to access a very narrow subset of resources, or even a single file, when that type labels only a single file.
  • It is targeted and designed for Android. See the adb_data_file.

Label the resources

To label a resource is also called to create a Security Contexts for a resource, or file contexts. The file contexts common to all devices are put in system/sepolicy/file_contexts. Vendor specific file contexts should reside in device/vendor/device/sepolicy. They will be combined together to generate the final file context during the build process.
Let's take a look at the common file_contexts.
# system/sepolicy/file_contexts
# truncated to show an overall view

# Root
/fstab\..*          u:object_r:rootfs:s0
/init\..*           u:object_r:rootfs:s0
/ueventd\..*        u:object_r:rootfs:s0

# Dev
/dev/audio.*        u:object_r:audio_device:s0
/dev/binder         u:object_r:binder_device:s0

# System
/system/bin/mediaserver     u:object_r:mediaserver_exec:s0
/system/bin/servicemanager  u:object_r:servicemanager_exec:s0
/system/bin/surfaceflinger  u:object_r:surfaceflinger_exec:s0

# Vendor
/vendor(/.*)?               u:object_r:system_file:s0
/vendor/bin/gpsd            u:object_r:gpsd_exec:s0

/odm(/.*)?                  u:object_r:system_file:s0
/oem(/.*)?                  u:object_r:oemfs:s0

# Data
/data/security(/.*)?  u:object_r:security_file:s0
/data/drm(/.*)?   u:object_r:drm_data_file:s0
/data/gps(/.*)?   u:object_r:gps_data_file:s0
A few takeaways:
  • It labels everything : normal file, device file, executables.
  • It labels everywhere : rootfs, system, vendor, data partitions.
  • It is tailed for Android, sometime its called SEAndroid.
The label follows form of user:role:type:sensitivity. From the example shown above, you can tell type is the most important part, since the other part are same in Android at the moment.
To check the context for files use ls -Z
$ ls -Z /system/bin/mediaserver
u:object_r:mediaserver_exec:s0 /system/bin/mediaserver

Define process domains, and label processes

Domain is similar to Type but used to label a process, instead of a file. To define a domain, use type keyword as well, but the second parameter is domain instead of xxx_type. See line (1) in follow code snippet.
    # mediaserver - multimedia daemon
    type mediaserver, domain, domain_deprecated;          (1)
    type mediaserver_exec, exec_type, file_type;          (2)  

    init_daemon_domain(mediaserver)                       (3)
However, labelling a process with a Domain is different from labelling the corresponding executable file (with a Type). For example, we know from preceding introduction that the /system/bin/mediaserver is labelled as u:object_r:mediaserver_exec:s0, and that's down to the mediaserver_exec type.
But, the domain of the process mediaserver of is mediaserver. And, we'll see late, when writing the rules, we will use domain mediasever, instead of mediaserver_exec.
$ ps -Z | grep mediaserver
u:r:mediaserver:s0    media   1662  1 44340  10456 /system/bin/mediaserver
It's not hard to imagine there is something done under the hood creating this association (or transition) between the exec type and process domain. That's done through the macro in line (3). For now, we can just pretend we know what it is.

Write rules that will apply to a process and resources.

A rule will roughly say "allow somebody do something on something". Or better, "allow a subject take some actions on an object". The subject here is the process; the object here are the resources, such files, sockets; and the actions are the permissions. We have already know how to label the subject and object, in order to write a rules, we also need to define the permission.


In DAC, we have three access permissions, read, write, execute, for all type of files. In SELinux, things are much more complex, for a good reason.
SELinux (or SEAndroid) defines a list of types, called security classes. Its includes File, Directory, File System, Socket, Processes, security and capability. A full list can be found at system/sepolicy/security_class.
For different classes, there are different permissions, or called access vectors. A full list can be found at system/sepolicy/access_vectors.
An simple explanation of the permissions defined by SELinux can be found here.
Among those security classes, there is a class called Process, which defines the permission a process itself can do, for example, whether the process is allowed to change the security context of its own and the child processes. This constraint can be done in DAC based model.

Final, write the policies.

Policy files is the place to put all the pieces together and do the ultimate job of imposing access control.
The policy file ends with .te suffix as well, same as the type definition files. They are organized by domains, for example bluetooth.te for bluetooth domain/service/daemon, mediaserver.te for mediaserver domain/service/daemon.
The format of the rule is:
rule_name source_type target_type : class perm_set;
Below is truncated code of mediaserver.te. It shows an example of how to control the access of different type of resources: files, directories, devices, sockets, process, and binder services. Most of the rules are (hopefully) self explanatory, if you had followed the discussion (and congratulation on that). What worth note is the ability to control the out going bind calls. It means you have add that explicitly in the policy file, if you want to use a new binder service, or call a new API of a binder service. This is really tough, and some may consider it is cumbersome. However, it makes the system more secure. Everything vital permission must be explicated allowed. That is the core idea of SELinux, or Mandatory Access Control (aka MAC) in general.
# /system/sepolicy/mediaserver.te:
# truncated, an example for different type of permissions: 

# files
allow mediaserver media_data_file:file create_file_perms;
# dirs
allow mediaserver oemfs:dir search;
# devices
allow mediaserver gpu_device:chr_file rw_file_perms;
allow mediaserver video_device:dir r_dir_perms;
# socket
allow mediaserver rild:unix_stream_socket { connectto read write setopt };
# process
allow mediaserver self:process ptrace;
# bind service
allow mediaserver activity_service:service_manager find;
allow mediaserver drmserver:drmservice { setPlaybackStatus openDecryptSession }
allow is the most used rule, and that is conform to the selinux's default denial model. There is also other rules, such as neverallow. This rule specifies that an allow rule must not be generated for the operation, even if it has been previously allowed.
For example, app.te states that app are never allowed to access the hardware device files. It is also a requirement in CTS, the neverallow rules in system/sepolicy are never allowed to be modified.
# Access to any of the following character devices.
neverallow appdomain {
}:chr_file { read write };

Rules in actions

sepolicy(.bin), file_context.bin and policy.conf

We have discussed a bunch of different files that are used to define the sepolicy. .te files are used either to define type , or rules; file_contexts are used to label the resources. Those are all human readable files, for obvious reason. And, not surprise, a binary representation will be generated from those file for efficiency. Among the binary files, two important ones are sepolicy(.bin) and file_contexts.bin, which are all end up in the root file system during the build process. And they will be used by selinux to enforce the rules.
The seplicy(.bin) is the output of checkpolicy, with an intermediate file called policy.conf as the input. In turn, the policy.conf is an aggregation of all the *.tefiles, among others. And, a good news is that policy.conf is text based, so we can diff that to diagnose policy issues between two version change.
Apart from the sepolicy.bin and, there are a few other files will be installed in either the rootfs or system partition during the build process, such as seapp_contexts, service_contexts and mac_permissions.xml. But we won't go details in this tutorial.

init and selinux in kernel

We have all the labels and rules in place but we haven't really set up anything yet. Say, apply a lable for a file. That is taken care by the init program.
Apart from the well know functionality such as read the init.rc, mount the partitions, and start the services, init also responsible for the initiation of selinux. It includes set up the labels for all the files according to the file_contexts.bin and pass the sepolicy to the kernel, among other things. Grep selinux_ in system/core/init/init.cpp for all the glory details.
How the selinux policy is actually enforced by the kernel is outside of the scope of this tutorial, but at least make sure the relevant configuration is enabled.


In this article, we start with why SELinux is introduced and the core idea of it - label every things, default denial, and explicit rules to allow anything. Then we look at the various components and steps need to implementation that stragey, in Android.
Hopefully at the end of the introduction, you are convinced that SELinux is a very effective way, if not the most effective way, to protect the device security. And I think SELinux should be mandatory on all the devices, be it mobile devices, IoT devices or servers. Of course, that mean they have to run Linux first, which is nice :)
For other stuffs such as enable/disable SElinux, how to interpret and fix the SELinux warning (svc message), you can check this official documentation.