A comparative analysis between DTE Linux, SELinux and Seandroid

In 2000, researchers at William Mary College in the United States, Serge, and others at the Usenix 4th annual Linux Showcase &conference Conference, published the title "Domainand Type Enforcement for Linux "article. The first time this article used the DTE model for Linux, the DTE Linux prototype system was implemented.

The same year, the NSA's Stephen Smalley and others released the open source Linux security framework Selinux,selinux the first version is based on the Linux 2.5 kernel and is published under the GPL open source protocol. In August 2003, SELinux was formally integrated into the 2.6.0 version of the Linux official kernel.

SELinux, as the current industry standard for DTE on Linux, is largely consistent with DTE Linux, but because the two results belong to different research teams, the specific mechanisms are still slightly different. Since there is a lot of information about DTE, this article introduces the difference between DTE Linux and SELinux from another angle. At the same time, because my research direction is Android security, SELinux also implemented on the Android system, called Seandroid, so this article will be combined with the Android system to illustrate a specific case of the SELinux policy configuration. This document mainly includes the following two parts: 1) The similarities and differences between DTE Linux and SELinux; 2) seandroid policy configuration case.

The 1th chapter the similarities and differences between DTE Linux and SELinux
1.1 In the same place

Both DTE Linux and SELinux implement the DTE model, including the following three types of access control:

1) Type Access

2) Domain Access

3) Domain Transition

1.2 Differences
1) Policy file storage mode is different

DTE Linux employs a centralized policy file scheme with a policy file storage path of/etc/dte.conf, while SELinux employs a decentralized policy file scheme that stores policy files under the/etc/selinux/folder, including policy.conf files. I personally think that the SELinux scheme is better, different policy files are more modular, convenient for different organizations, companies for their own responsible program logic to write policy, and finally through the policy compilation, all SELinux policy files are compiled into a complete policy library, the kernel can run efficiently, No efficiency loss is incurred.

2) The order differs from the conventional DAC judgment logic

DTE Linux, when accessing authorization, judged the DTE policy and then judged the DAC strategy, whereas SELinux instead judged the DAC policy before judging the DTE policy. I personally think that the selinux implementation is better, considering that the DTE policy is designed to prevent malicious attacks, and only if the DTE policy does deny when an attack occurs, the likelihood that one access is normally denied by the DAC policy is much higher than the likelihood of being rejected by the DTE policy, so from a performance standpoint, It is appropriate to put the DAC policy judgment logic in front.

3) Whether the code implementation relies on LSM

LSM is the short name of the Linux secrity module, the Linux security module. It is a lightweight universal access control framework that is suitable for a variety of access control models on which the kernel loadable modules are implemented. Users can choose the right security module to load to the kernel according to their own needs. The LSM framework was integrated into the Linux 2.6 official code in December 2003. LSM currently supports a variety of security frameworks including Apparmor,selinux, Smack and Tomoyo Linux. (after a few years of publication, DTE Linux was also implemented in the Linux 2.6 lsm)

The DTE Linux article was the author's own prototype system based on the Linux 2.3 version, which was earlier and did not have the LSM framework at the time, so all the function hooks, the newly added system calls, were done by the DTE for Linux prototype system itself.

The SELinux framework was developed on the basis of LSM. There is an episode: the 2001 Linux Kernelsummit Conference at the NSA found the Linux founder Linus wanted to integrate SELinux into Linux 2.5, Linus then rejected the request, This is because there are many other security frameworks beyond SELinux, and the Linux community cannot agree on which framework to adopt. So Linus decided to make the security framework "a module", and subsequently had LSM and LSM-based SELinux.

4) supported models are different

While the DTE model is only involved in the DTE Linux article, SELinux implements the RBAC model and the MLS model (optional) while implementing the DTE models.

2nd Chapter seandroid Policy configuration case

Seandroid Full Name Security enhancements (SE) for Android, is an implementation of SELinux on the Android operating system. Currently, Seandroid is not limited to SELinux, and has begun to develop new security features specifically for Android-enabled systems.

I've recently been working on Android security hardening, which involves a real case of configuring SELinux policies. Requirements are: to ensure that the production and maintenance personnel sufficient authority, to prevent ordinary users from obtaining root privileges. Here we mainly say how to ensure that the production and maintenance personnel full authority, in essence, the implementation of "root command call path."

Our proposal is to:

Provides a native level service running at the root level, providing a command execution interface for upper-level applications to make IBinder inter-process calls that require a security key to ensure that only the application is able to invoke the root command through the service. At the same time, the native-level service has some robustness, and when it is shut down, the system will automatically restart the native level service.

Some functions of this program, such as network access control, need to be iptables rule configuration, and iptables configuration is required to use root permissions. To ensure that top-level applications can use root permissions, this scenario requires a sufficiently secure root access path that is designed for use by upper-level applications. This method mainly relies on native level service implementation. When a top-level application requires special permissions, the native service is called, and the native level service invokes the associated command with root permission and returns the result to the application layer after the security key has been successfully verified.

Currently our program is implemented on Android5.1, Android5.1 on the default SELinux function, and its policy settings are very strict, our scheme is rejected by many SELinux policies can not be successfully executed, so we need to modify the SELinux policy, open a "Cut" to release our native-level service calls.

There are two main steps to the SELinux policy tuning scenario:
1) Add Tags:

1. Declare the type label of the Peki service as Pekiserver_service

\51droid\android-5.1.0_r3\external\sepolicy\service_contexts

line:123 Add:

Peki U:object_r:pekiserver_service:s0

2. Define a sub-label of type label Pekiserver_service to Service_manager_type

\51droid\android-5.1.0_r3\external\sepolicy\service.te

Line:13 Add:

Type Pekiserver_service, Service_manager_type;

3. Declare the type label of the Pekiserver daemon as Pekiserver_exec

\51droid\android-5.1.0_r3\external\sepolicy\file_contexts

line:166 Add:

/system/bin/pekiserver U:object_r:pekiserver_exec:s0

2) Configuration rules:

4. Add te policy File Pekiserver.te

\51droid\android-5.1.0_r3\external\sepolicy\

Add Pekiserver.te File

The contents of the Pekiserver.te file are as follows:

# Pekiserver-peki ServiceType pekiserver, Domain;type pekiserver_exec, Exec_type, File_type;init_daemon_domain ( Pekiserver) Typeattribute pekiserver Mlstrustedsubject;net_domain (pekiserver) # Perform Binder IPC to System Server.binder_use (Pekiserver) Binder_call (Pekiserver, System_server) Binder_call (Pekiserver, AppDomain) Binder_ Service (pekiserver) # Add serviceallow pekiserver pekiserver_service:service_manager add;# Execute commandsallow  Pekiserver Shell_exec:file {Execute Execute_no_trans read Open};allow pekiserver system_file:file {Execute_no_trans};# Popen () failed to execute ' iptables-l ' Allow Pekiserver self:rawip_socket {Create getopt setopt};allow pekiserver self: Capability {Net_raw net_admin};# Read iptables configuration file:/data/pekisafe/ctx_current/iptables_cfg.txtallow Pekiserver system_data_file:file {Open Read};

After the SELinux policy has been adjusted, the native service call executes successfully, as shown in the Iptables firewall rule that can be displayed in the app properly.

A comparative analysis between DTE Linux, SELinux and Seandroid