It is recommended that you first look at the contents of the previous blog post ([Android l]seandroid enhanced Androd Security Background summary and impact), first to see the full picture of seandroid, and then continue this section. 1 phenomenon description based on the Android L version of the source code environment for development, according to project requirements, the app layer needs to operate SYS/XXX or proc/xxx the following file nodes, but will report the following permissions exceptions, unable to directly manipulate these nodes Ledlightfileutil (4671) : java.io.FileNotFoundException:/sys/class/leds/green/brightness:open failed:eacces (Permission denied) Ledlightfileutil (4671): at Libcore.io.IoBridge.open (iobridge.java:456) Ledlightfileutil (4671): at Java.io.fileoutputstream.<init> (fileoutputstream.java:87) Ledlightfileutil (4671): at Java.io.fileoutputstream.<init> (fileoutputstream.java:127) Ledlightfileutil (4671): at Java.io.fileoutputstream.<init> (fileoutputstream.java:116) 2 problem reason since the Android L version, Google is generally enabled for the source environment SELinux security access mechanism, the app and the framework layer by default no access to device nodes such as (SYS/XXX,PROC/XXX) 3 workaround Here are three common operational perspectives on how to open permissions for a system app process or system server process
1) SEAndroid to open access (read or write) permissions for sys device file nodes (for example:/sys/class/leds/green/brightness)
2) SEAndroid method for opening access (read or write) permissions for proc device file nodes (e.g.,/proc/touchscreen_feature/gesture_data)
3) SEAndroid to open set (write) permissions for systemproperties custom properties 3.1 seandroid the method for opening access (read or write) permissions for sys device file nodes (for example:/sys/class/leds/green/brightness) to operate the LED Lamp device file node as an example, such as green light:/ sys/class/leds/green/brightness, open the node access rights (read or write) for the app layer system app process green:/sys/class/leds/green/brightness//Shortcut/sys/ devices/soc.0/gpio-leds.66/leds/green/brightness//Actual node ps: The default is under the External/sepolicy directory, However, both the MTK platform and the Qcom platform create their own directories for managing SELinux policy: mtk:alps/device/mediatek/common/sepolicyqcom:android/device/qcom/ Sepolicy/common so it is recommended that you in their platform under the corresponding directory to operate, the following qcom platform for example, MTK platform configuration step method is the same (Alps/device/mediatek/common/sepolicy) 3.1.1 In Android/device/qcom/sepolicy/common/file.te, define the SELinux type:sysfs_wingtk_leds as follows: Type sysfs_wingtk_ LEDs, Fs_type, sysfs_type; 3.1.2 in android/device/qcom/sepolicy/common/file_contexts, bound Sysfs_wingtk_ LEDs to the corresponding actual node, note is the actual node/sys/devices/soc.0/gpio-leds.66/leds/green/brightness u:object_r:sysfs_wingtk_leds:s0 ps:/sys/class/leds/green/brightness can also be declared, the sentence is not necessary:/sys/class/leds/green/brightness u:object_r: sysfs_wingtk_leds:s0 Summary: File_contexts is modified as follows:/sys/class/leds/green/brightness u:object_r:sysfs_wingtk_leds:s0/sys/devices/soc.0/gpio-leds.66/leds/green/ Brightness u:object_r:sysfs_wingtk_leds:s0 3.1.3 in Android/device/qcom/sepolicy/common/system_app.te, request permission: Allow System_app sysfs_wingtk_leds:file Rw_file_perms; ps: You can also request related permissions for other process, such as: System_server, In Android/device/qcom/sepolicy/common/system_server.teallow system_server sysfs_wingtk_leds:file rw_file_perms; ps: When configuring the actual node of step 2nd, how to get the actual node, the method is as follows: [email protected]:/sys/class/leds # ll-zlrwxrwxrwx root root u:object _R:SYSFS:S0 Flashlight. /.. /devices/soc.0/flashlight.64/leds/flashlightlrwxrwxrwx root root U:object_r:sysfs:s0 green. /.. /devices/soc.0/gpio-leds.66/leds/greenlrwxrwxrwx root root u:object_r:sysfs:s0 lcd-backlight. /.. /devices/soc.0/1a00000.qcom,mdss_mdp/qcom,mdss_fb_primary.124/leds/lcd-backlightlrwxrwxrwx 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/redlrwxrwxrwx root root u:object_r:sysfs:s0 torch-light0. /.. /devices/soc.0/qcom,camera-led-flash.65/leds/torch-light0[email protected]:/sys/class/leds # through The ll-z command can be found. 3.1.4 in Androidmanifest.xml, configuration: android:shareduserid= "Android.uid.system", the step must be, because the third step is: Allow System_app sysfs_wingtk_leds:file rw_file_perms; //only allow System_app process access . After four steps, the app layer can read and write:/sys/class/leds/ green/brightness in order to better control access, if there is an app layer and the framework layer to access a device node, I think it is best to use this mode to access the device node, that is, not to let the System_app process access, only allow the system The _server process is accessed as follows: Allow System_server sysfs_wingtk_leds:file rw_file_perms; disadvantage: You need to add a service that starts with the system at the framework layer, Increased code Volume Advantages: 1. You have free control over which apps are accessible, which apps prohibit access to already open device nodes, and can better protect security issues &NBSP;2. Both the framework layer and the app layer can access the device node. No additional permissions are requested 3.2 seandroid methods for opening access (read or write) permissions for proc device file nodes (such as:/proc/touchscreen_ Feature/gesture_daTA), take the MTK platform as an example to modify the record details expand 3.2.1 define SELinux type:proc_quick_gesture in Alps/mediatek/common/sepolicy/file.te as follows: type Proc_quick_gesture, fs_type; 3.2.2 in alps/mediatek/common/sepolicy/genfs_contexts, bound Proc_quick_ Gesture to the corresponding actual node Genfscon proc/touchscreen_feature/gesture_data u:object_r:proc_quick_gesture:s0 3.2.3 in Alps/mediatek/common/sepolicy/common/system_app.te, request permission System_app proc_quick_gesture:file Rw_ file_perms; 3.2.4 in Androidmanifest.xml, configuration: android:shareduserid= "Android.uid.system" after the above 4 steps, System_ The app process has permission (read or write) to access nodes such as/proc/touchscreen_feature/gesture_data 3.3 seandroid Methods for opening set (write) permissions for systemproperties custom Properties The problem description systemproperties no write permission on the custom attribute, that is, the set prompt does not have permission, causing the write unsuccessful resolution to " Persist.backgrounddata.enable "For an example of the Open Attribute permission method Qcom platform as an example 3.3.1 android/device/qcom/sepolicy/common/ Property.tetype Persist_backgrounddata_prop, property_type; 3.3.2 android/device/qcom/sepolicy/common/ Property_contextspersist.backgrounddata.enable U:object_r:persiSt_backgrounddata_prop:s0 3.3.3 android/device/qcom/sepolicy/common/system_app.te, for System_. App process open permissions allow System_app Persist_backgrounddata_prop:property_service set; 3.3.4 in Androidmanifest.xml, Configuration: android:shareduserid= "Android.uid.system" after 4 steps above, you can use the Systemproperties.set (" Persist.backgrounddata.enable "", XX) set the property. Extended Reading If you do not have permission to read or write to the SYS or proc node after the above steps are properly configured, Dan is not broken. I'll tell you what, you need to go to init.rc. Configure: Chown system System File node, and then chmod next file node. Two platform configuration paths, different items differ slightly mtk:alps/device/mediatek/mt6735/init.mt6735.rcqcom:xx/xx/init.target.rc turn from:/http blog.csdn.net/yelangjueqi/article/details/46761987
[Android l]seandroid Open Device File node permissions (read or write) method (covers common operations: Sys/xxx, Proc/xxx, systemproperties)
