Seandroid resolution CASE

are extracted from the network summary down the standby, some links are missing

Read and write through the System Server service or INIT-initiated service, and then the app connects to the app via Binder/socket, and so on. This kind of safe and reliable, and can do related security review in service, esteem this method.

Since the Android L version, Google has generally enabled the SELinux security access mechanism for the source environment, and the app and framework layer does not have access to device nodes by default (SYS/XXX,PROC/XXX)

The following methods for opening permissions for the System app process or system server process are described in three common operations

1 Seandroid method for open access (read or write) permissions for sys device file nodes (e.g.,/sys/class/leds/green/brightness)
2 seandroid for proc device file node open access (read or write) permission methods (such as:/proc/touchscreen_feature/gesture_data)
3 Seandroid A method of opening set (write) permissions for systemproperties custom attributes

first, seandroid for SYS device file node open access (read or write) permission methods (such as:/sys/class/leds/green/brightness)

such as green light:/sys/class/leds/green/brightness, open the node access (read or write) for app layer system app process

/sys/class/leds/green/brightness//Shortcuts
/sys/devices/soc.0/gpio-leds.66/leds/green/brightness//Actual node

Mtk:alps/device/mediatek/common/sepolicy
Qcom:android/device/qcom/sepolicy/common

1.1 in Android/device/qcom/sepolicy/common/file.te, define SELinux type:sysfs_wingtk_leds, as follows:

Type Sysfs_wingtk_leds, Fs_type, Sysfs_type;

1.2 in Android/device/qcom/sepolicy/common/file_contexts, bind sysfs_wingtk_leds to the corresponding actual node, note that the actual node

get the actual node can be passed, ll-z command can be found.

root@k31-t7:/sys/class/leds # ll-z lrwxrwxrwx root root u:object_r:sysfs:s0 flashlight. /.. /devices/soc.0/flashlight.64/leds/flashlight lrwxrwxrwx root root u:object_r:sysfs:s0 green->. /.. /devices/soc.0/gpio-leds.66/leds/green lrwxrwxrwx root root u:object_r:sysfs:s0 lcd-backlight->. /.. /devices/soc.0/1a00000.qcom,mdss_mdp/qcom,mdss_fb_primary.124/leds/lcd-backlight lrwxrwxrwx root root u:object_r: Sysfs:s0 mmc0::->. /.. /devices/soc.0/7824900.sdhci/leds/mmc0:: lrwxrwxrwx root root u:object_r:sysfs:s0 mmc1::->. /.. /DEVICES/SOC.0/7864900.SDHCI/LEDS/MMC1:: lrwxrwxrwx root root u:object_r:sysfs:s0 red->. /.. /devices/soc.0/gpio-leds.66/leds/red lrwxrwxrwx root root u:object_r:sysfs:s0 torch-light0->. /.. /devices/soc.0/qcom,camera-led-flash.65/leds/torch-light0 Root@k31-t7:/sys/class/leds # 

/sys/devices/soc.0/gpio-leds.66/leds/green/brightness U:object_r:sysfs_wingtk_leds:s0

/sys/class/leds/green /brightness                      u:object_r:sysfs_wingtk_leds:s0

PS: You can put the/sys/class/leds/green/brightness also declared that the sentence is not necessary:

1.3 in Android/device/qcom/sepolicy/common/system_app.te, apply for permission:

Allow System_app sysfs_wingtk_leds:file rw_file_perms;

PS: You can also request related permissions for other process requests, such as: System_server, in Android/device/qcom/sepolicy/common/system_server.te

Allow System_server sysfs_wingtk_leds:file rw_file_perms;

1.4 in Androidmanifest.xml, configuration: android:shareduserid= "Android.uid.system", this step is necessary, because the third step is:

Allow System_app sysfs_wingtk_leds:file rw_file_perms; Only System_app process access is allowed.

after four steps, the app layer can read and write normally:/sys/class/leds/green/brightness in order to better control access, if there is an app layer and framework layer to access a device node, I think it is best to access the device node in this way, that is, to not allow the System_app process access, only to allow system_server processes to access, such as

Allow System_server sysfs_wingtk_leds:file rw_file_perms;

Disadvantages:
Need to add a service that starts with the system at the framework layer to increase the amount of code
Advantages:
1. The freedom to control which applications can be accessed and which applications prohibit access to already open device nodes can better protect security issues
The device node is accessible to both the 2.framework layer and the app layer. No additional permission to apply

Second, the proc device file node open access (read or write) permission methods (such as:/proc/touchscreen_feature/gesture_data), the MTK platform as an example

The 2.1 defines SELinux type:proc_quick_gesture in Alps/mediatek/common/sepolicy/file.te, as follows:

 Type proc_quick_gesture, Fs_type;

2.2 In Alps/mediatek/common/sepolicy/genfs_contexts, bind proc_quick_gesture to the corresponding actual node

Genfscon Proc/touchscreen_feature/gesture_data   U:object_r:proc_quick_gesture:s0

2.3 In Alps/mediatek/common/sepolicy/common/system_app.te, apply for permission

2.4 androidmanifest.xml, configuration: android:shareduserid= "Android.uid.system", set to System_app process with permissions (read or write) Access/proc/ Touchscreen_feature/gesture_data and other nodes.

systemproperties Custom Properties open Set (Write) Permission method (problem description systemproperties does not have write permission to custom attribute, that is, set when prompt does not have permission, cause write unsuccessful)

An example of "persist.backgrounddata.enable": An Introduction to open Attribute permission method

Take the qcom platform as an example
3.1 android/device/qcom/sepolicy/common/property.te

 type Persist_backgrounddata_prop, property_ type;

3.2 android/device/qcom/sepolicy/common/property_contexts

 persist.backgrounddata.enable u:object_r:persist_ Backgrounddata_prop:s0

3.3 android/device/qcom/sepolicy/common/system_app.te, open permissions for System_app process

 allow System_app Persist_backgrounddata_prop:property_service set;

3.4  in Androidmanifest.xml, configuration: android:shareduserid= "Android.uid.system"

you can set the properties using Systemproperties.set ("Persist.backgrounddata.enable", XX) in your code.

Extended Reading
If you are properly configured with the above steps, you still do not have permission to read or write to the SYS or proc node, Dan is broken. Again, you need to go to init.rc to configure: Chown system System File node, then chmod the file node. Two platform configuration paths with slightly different project differences
Mtk:alps/device/mediatek/mt6735/init.mt6735.rc
Qcom:xx/xx/init.target.rc

Iv. seandroid access to the dev node

1. First identify the processes (process) that require access to the kernel node, currently we are using System_server to access

 2. Open File Androidl/android/external/sepolicy/file_ contexts.be
 /dev/wf_bt              u:object_r:wf_bt_device:s0  
 Wf_bt_device is a custom, and the other left and right sides of the content are consistent with the above example.

 3.: Open the file Androidl/android/external/sepolicy/device.te
 imitate this document in the writing, will just write the second step Wf_bt_device declared as Dev_type:

 Type Wf_bt_device, Dev_type;  

 4.androidl/android/external/sepolicy/ There are many. te files are terminated by the process name, such as the Surfaceflinger for the Surfaceflinger process, the vold.te for the vold process,
 just from the first step, this node is made up of system_ Server process to access, so we find system_server.te open, join allow this process to/DEV/WF_BT read and write permissions,

 allow System_server wf_bt_device:chr_file rw_ file_perms;  

 Allow the system_server process to have read and write access to this character device for Wf_bt_device.
 After you have changed these, you can make installclean;make-j16 compile image to verify that the permissions are successful.


 

v. Add permissions for executing script processes

http://blog.csdn.net/jiuxiaoyunwu/article/details/51220477

5.1 init.rc or other init.project.rc

On Post-fs-data///Add the following code below this node  
chmod 0777/system/bin/cloudtestsuited on  

init//Add the following code service under this node  
Cloudtestsuited/system/bin/cloudtestsuited  
         class main  
         oneshot  
         disabled  


or can be in init.rc before declaring service Add a line of code,
on property:sys.service.silead=enabled and then apk to execute the following code, provided APK has platform signature, system permission

The oneshot option means that the service is only started once, and if the oneshot option is not available, the executable will always exist – reboot if the executable program is killed.
Disabled indicates that the service is disabled and will not start automatically when it is powered on, but it can be started manually in the application.

5.2 Add the corresponding SELinux permission
Add the bin service's corresponding permissions in the Device\mediatek\common\sepolicy\file_contexts file:

/system/bin/cloudtestsuited U:object_r:fpsvcd_exec:s0  

5.3 Add the bin service corresponding permissions in the Device\mediatek\common\sepolicy\system_app.te file .

Allow system app Do:add for fp.apk create file under '/data/silead/' file path

Allow System_app Fpsvcd_data_file:dir {Create write Add_name remove_name read Open search};  
Allow System_app fpsvcd_data_file:file {unlink GetAttr Create write Open read};  
Add for starting cloudtestsuited in apk  
allow System_app fpsvcd_tmpfs:file {Read write open getattr};  
Allow System_app fpsvcd_exec:file {getattr read execute open Execute_no_trans};  
Allow System_app Fpsvcd:dir {read Open};  
Allow System_app Tmpfs:dir {read Write getattr};  

5.4 Add a permission file in the device\mediatek\common\sepolicy\ directory Fpsvcd.te:

Type fpsvcd_exec, Exec_type, File_type;  
Type FPSVCD, domain;  
Init_daemon_domain (FPSVCD) ...
...

5.5 Start Service

Systemproperties.set ("Sys.service.silead", "Enabled"); or private void Startcloudserver () {New Thread (new Runnable () {@Override public void R Un () {try {log.v (const.tag_log, TAG + startcloudserver)
                    ->getruntime cloudtestsuited ");
                    string[] cmd = new string[] {"Su", "-C", "cloudtestsuited"};
                    string[] cmd = new string[] {"sh", "C", "cloudtestsuited"};
                    Process proc = Runtime.getruntime (). exec (CMD);
                    Proc.waitfor ();
                Excutecmd_multithread (CMD); catch (Exception e) {log.e (Const.tag_log, TAG + "Startcloudserver occu
                RS exception, ", E); try {log.v (const.tag_log, TAG + startcloudserver->)
         Systemproperties cloudtestsuited ");           Systemproperties.set ("Ctl.start", "ztstartsileadcloudtest"); catch (Exception e) {log.e (Const.tag_log, TAG + "Startcloudserver occu
                RS exception, ", E);
    }}). Start (); } private void Excutecmd_multithread (string[] cmd {try {Process proc = runtime.getruntime (). ex
            EC (CMD);
            Thread errorthread = new Thread (New Inputstreamrunnable (Proc.geterrorstream (), "Errorstream"));
            Errorthread.start ();
            Thread outputthread = new Thread (New Inputstreamrunnable (Proc.getinputstream (), "OutputStream"));
            Outputthread.start ();
        Proc.waitfor (); catch (Interruptedexception e) {log.e (Const.tag_log, TAG + "Excutecmd_multithread occu
        RS Interruptedexception, ", e); The catch (IOException e) {LOG.E (const.tag_LOG, TAG + "excutecmd_multithread occurs IOException,", e);
        } Private class Inputstreamrunnable implements Runnable {BufferedReader breader = null;

        String type = null;
                Public Inputstreamrunnable (InputStream is, String TypeCode) {try {type = TypeCode; Breader = new BufferedReader (new InputStreamReader) (New Bufferedinputstream (IS), "UTF-8")
            ; catch (Exception e) {log.e (Const.tag_log, TAG + "inputstreamrunnable occurs ex
            Ception, ", e);
            @Override public void Run () {String line;
            int linenum = 0;
                        try {while (line = Breader.readline ())!= null) {if ("Errorstream". Equals (type)) {
                    LOG.E ("Fpcloudserver ERROR", line); else if ("OutputStream". Equals (type)) {log.i ("Fpcloudserver Output", line);
                    else {log.v ("Fpcloudserver Debug", line);
                } linenum++;
                } if (Breader!= null) {breader.close (); The catch (Exception e) {log.e (Const.tag_log, TAG + "Inputstreamrunn
            Able run occurs exception, ", E);

 }
        }
    }

vi. recovery operation download Directory

the definition in 6.1 recovery.te

Neverallow recovery data_file_type:file {no_w_file_perms no_x_file_perms};  
Neverallow recovery Data_file_type:dir no_w_dir_perms;  

6.2 Let's look at the definition of system_data_file in File_contexts.te.

/data (/.*)?     U:object_r:system_data_file:s0  

6.3 While the File.te defines the System_data_file file as a data_file_type type, recovery is also unable to manipulate files under Data

File.te:56:type System_data_file, File_type, Data_file_type;  

6.4 Solution: When we can define our own file type, we can define data/download belong to Download_data_file type

 (1) filecontext.te definition/data/download (/.*)?   


U:OBJECT_R:DOWNLOAD_DATA_FILE:S0 (2) then defines the Download_data_file type download_data_file in File.te, File_type;  
(3) Then add the rights to the Download_data_file in Recovery.te allow recovery Download_data_file:dir {write search remove_name};  



Allow recovery Download_data_file:file {read GetAttr unlink}; (4) In addition we also need to download the upgrade package in a systemapp, so we need to add the following permissions in System_app.te: Allow System_app download_data_file:dir {search Write add_  
Name GetAttr Remove_name};  


Allow System_app download_data_file:file {Create read write open GetAttr unlink}; (5) But finally failed, why, because the first did not data/download this directory, but we have to download the app itself when the directory created, so it is system_data_file type. Then we need to have the Data/download directory at the beginning, so add the following code to the INIT.RC: Mkdir/data/download 0771 System System (6)

Finally, we need to add the following in the Uncrypt.te, because the data directory may require encryption processing.  
Allow Uncrypt download_data_file:dir {search GetAttr};  Allow Uncrypt download_data_file:file {getattr read Open}; 

Vii. Adding device type operations

http://blog.csdn.net/lushengchu_luis/article/details/52775740

Inadvertently see this article online, in Device.te add type Serial_device, Dev_type, mlstrustedobject; this line, the problem is solved
Third-party signature app, under SELinux, how to gain access to a kernel node

In android6.0, apps that are not allowed to be signed by a third party are assigned mlstrustedsubject for security reasons:

7.1 In the External/sepolicy/untrusted_app.te file:

# Don't allow Untrusted_app to be assignedmlstrustedsubject.
# This would undermine the Per-user isolation model being
# enforced via Levelfrom=user in Seapp_contexts and the mls< c2/># constraints.  As there is no direct way tospecify a neverallow
# on attributes assignment, this relies on the fact that Fork
# PE Rmission only makes sense within a domain (hence should
# never is granted to no other domain Withinmlstrustedsubject )
# and Untrusted_app is allowed fork permission to itself.

Neverallow Untrusted_app mlstrustedsubject:process Fork;

7.2 So in the use of Third-party signature app, I hope that a third party signed app a process can operate on the kernel node, as follows:

1. Add in device/sprd/scx20/common/sepolicy/file_contexts file:
/dev/abc u:object_r:abc_device:s0 

2. In device/ Sprd/scx20/common/sepolicy/device.te file Add:
type Abc_device, Dev_type, Mlstrustedobject;

7.3 Add in Device/sprd/scx20/common/sepolicy/untrusted_app.te file:

Allow Untrusted_app adc_device:chr_fileoperate;

operate to the given permission.

Note:

Mlstrustedsubject: This attribute contains all the main domain that can cross the MLS check.

Mlstrustedobject: This attribute contains all the object type that can be checked over MLS.