Develop Reference

Android SELinux: allow sys_ptrace for custom daemon

I am writing daemon for LineageOS which must be able to monitor running processes. But when I have started build I have run into SEPolicy neverallows. Investigating further sepolicy I have found the following rule in system/sepolicy/private/domain.te:
neverallow {
domain
-vold
userdebug_or_eng(`-llkd')
-dumpstate
userdebug_or_eng(`-incidentd')
-storaged
-system_server
} self:global_capability_class_set sys_ptrace;
Is it possible to somehow bypass this rule without changing code of LineageOS system sepolicy. I have tried the following:
type valord, coredomain, domain;
type valor_db, file_type;
type valord_exec, exec_type, file_type;
init_daemon_domain(valord)
domain_auto_trans(init, valord_exec, valord)
# NOFIX: The valord do not detects proccess when it
# is not given sys_ptrace capability. Since is is
# in neverallow's we have no way but to rewrite neverallow
neverallow {
domain
-valord
-vold
userdebug_or_eng(`-llkd')
-dumpstate
userdebug_or_eng(`-incidentd')
-storaged
-system_server
} self:global_capability_class_set sys_ptrace;
# ...
# Some allow's that are verified to pass
# ..
allow valord self:global_capability_class_set sys_ptrace;
but it still failed with the error that my policy violates above mentioned neverallow in system/sepolicy/private/domain.te
P.S.: The denial message is: 11-12 01:06:22.582 3369 3369 W valord : type=1400 audit(0.0:71): avc: denied { sys_ptrace } for capability=19 scontext=u:r:valord:s0 tcontext=u:r:valord:s0 tclass=capability permissive=0

Use custom RenderScript in system signed application

How to use custom RenderScript script in an application which is signed by system certificate?
LogCat output:
E/RenderScript: Failed loading RS driver: dlopen failed: cannot locate symbol "_ZN7android12renderscript15RsdCpuReference6createEPNS0_7ContextEjjPFPKNS1_9CpuSymbolES3_PKcEPFPNS1_9CpuScriptES3_PKNS0_6ScriptEEPFPN4llvm6ModuleEPN3bcc8RSScriptESK_SK_EPFS8_S8_jES8_" referenced by "/system/vendor/lib/libRSDriver_adreno.so"...
E/RenderScript: Failed to load runtime libRSDriver_adreno.so, loading default
W/EventThread: type=1400 audit(0.0:200): avc: denied { execute } for path="/data/user_de/0/[packageName]/code_cache/com.android.renderscript.cache/librs.rgb2yuv.so" dev="mmcblk0p25" ino=65890 scontext=u:r:system_app:s0 tcontext=u:object_r:system_app_data_file:s0 tclass=file permissive=0
W/EventThread: type=1300 audit(0.0:200): arch=40000028 syscall=192 per=800008 success=no exit=-13 a0=9aa80000 a1=6c0 a2=5 a3=12 items=0 ppid=336 ppcomm=main auid=4294967295 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=4294967295 exe="/system/bin/app_process32" subj=u:r:system_app:s0 key=(null)
W/auditd: type=1323 audit(0.0:200): fd=120 flags=0x12
W/auditd: type=1327 audit(0.0:200): proctitle="[packageName]"
W/auditd: type=1320 audit(0.0:200):
E/RenderScript: Unable to open shared library (/data/user_de/0/[packageName]/code_cache/com.android.renderscript.cache/librs.rgb2yuv.so): dlopen failed: couldn't map "/data/user_de/0/[packageName]/code_cache/com.android.renderscript.cache/librs.rgb2yuv.so" segment 0: Permission denied
It looks like the permission issue because this file /data/user_de/0/[packageName]/code_cache/com.android.renderscript.cache/librs.rgb2yuv.so exists on the phone.
I have my own Android OS build (Lineage 14.1 to be specific), so I'm able to alter privileges. I've already managed to give my application access to video_device (by excluding system_app from neverallow block in sepolicy repository app.te file). But I'm unable to find any connection between system app and renderscript privileges.

I've finally managed to resolve this issue.
RenderScript code is being compiled to shared library file (.so) and placed in /data directory/partition. SELinux policy, implemented in LineageOS14.1 is preventing system_app (this is a type to which policy rules are "assigned", and application signed by system certificate is recognized as this type), to execute on system_app_data_file (this is type identifying directory in which various system application data are stored, in my case compiled RenderScript libraries).
Loading library requires execute permission, and that is why the log is printed (denied {execute} ... ).
So, what can be done with it?
In AOSP, /system/sepolicy repository needs few changes:
1 system_app.te: Allow system_app to execute on system_app_data_file
diff --git a/system_app.te b/system_app.te
index 50320c5..25ebf06 100644
--- a/system_app.te
+++ b/system_app.te
## -11,6 +11,7 ## binder_service(system_app)
# Read and write /data/data subdirectory.
allow system_app system_app_data_file:dir create_dir_perms;
allow system_app system_app_data_file:{ file lnk_file } create_file_perms;
+allow system_app system_app_data_file:{ file lnk_file } { execute };
# Read and write to /data/misc/user.
allow system_app misc_user_data_file:dir create_dir_perms;
However, this modification is not enough - building ASOP now will finish with an error saying that other rules are conflicting with this one.
2 app.te: Add system_app_data_file as exception to neverallow executing from /data
diff --git a/app.te b/app.te
index 19a7dac..7a34645 100644
--- a/app.te
+++ b/app.te
## -453,18 +454,19 ## neverallow appdomain {
# Blacklist app domains not allowed to execute from /data
neverallow {
bluetooth
isolated_app
nfc
radio
shared_relro
system_app
} {
data_file_type
-dalvikcache_data_file
-system_data_file # shared libs in apks
+ -system_app_data_file
-apk_data_file
}:file no_x_file_perms;
This rule, without my change, is preventing system_app from executing on files - modification adds an exception for system_app_data_file.

Why is this access denied by SELinux

I have a unix socket daemon in my audio HAL, which I need to connect to from my app.
I get SELinux denied log as follows:
08-08 10:38:01.939 2622-2622/com.xxx.xxx.xxx W/ksetsdk.xxx: type=1400 audit(0.0:511): avc: denied { connectto } for path=0023xxx scontext=u:r:system_app:s0 tcontext=u:r:audioserver:s0 tclass=unix_stream_socket permissive=0
This is printed even though my app is signed with platform key, is installed in system.img and runs as system:
root#hikey:/ # ps | grep xxx
system 2619 1893 1561788 86956 SyS_epoll_ 0000000000 S com.xxx.xxx.xxx
root#hikey:/ # ps -Z | grep xxx
u:r:system_app:s0 system 2619 1893 1561788 86736 SyS_epoll_ 0000000000 S com.xxx.xxx.xxx
root#hikey:/ #
And I have added SEPolicy as follows:
auditallow system_app audioserver:unix_stream_socket { ioctl read getattr write setattr lock append bind connect getopt setopt shutdown connectto };
Can anyone guide me on what I missed? Is there any rule in AOSP SEPolicy that contradicts with this one? How do I get it to work?

There must've been some sync issue in my building aosp and changing SEPolicy rules.
I did more exhaustive testing and found:
(1) When app is signed by platform key, and requests system uid in manifest, it runs as system_app and following rule works:
auditallow system_app audioserver:unix_stream_socket { connectto };
(2) When app is signed by platform key, but doesn't request system uid in manifest, it runs as platform_app but following rule doesn't work:
auditallow platform_app audioserver:unix_stream_socket { connectto };
(3) If App is not signed by platform key, it runs as priv_app, and following rule doesn't work:
auditallow priv_app audioserver:unix_stream_socket { connectto };
I must've mixed up what rule was built into AOSP when I tested it.
It is still a mystery to me why priv_app or platform_app won't work, but system_app would with similar rule.

SELinux issue in Android 6

Im having an issue allowing an untrusted app in Android 6 to access the /dev/HSL1 serial interface. This is the error im getting:
[ 757.742286] type=1400 audit(156811.349:149): avc: denied { write } for pid=6422 comm="port_api.sample" name="ttyHSL1" dev="tmpfs" ino=7287 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:tty_device:s0 tclass=chr_file permissive=0
The file in question is /dev/ttyHSL1:
1|root#msm8909:/dev # ls -alZ ttyHSL1
crwxrwxrwx root root u:object_r:tty_device:s0 ttyHSL1
The external/sepolicy/untrusted_app.te has the following at the very end of the file:
allow untrusted_app tty_device:chr_file rw_file_perms;
allow untrusted_app device:dir r_dir_perms;
allow untrusted_app tty_device:chr_file write;
I would assume the rw_file_perms macro gives the rw access to the ttyHSL1 file, however its not so from the dmesg output (above). Also app fails with "You do not have r/w permissions on the serial port".
Additionally a snippet from global_macros:
#####################################
# Common groupings of permissions.
#
define(`x_file_perms', `{ getattr execute execute_no_trans }')
define(`r_file_perms', `{ getattr open read ioctl lock }')
define(`w_file_perms', `{ open append write }')
define(`rx_file_perms', `{ r_file_perms x_file_perms }')
define(`ra_file_perms', `{ r_file_perms append }')
define(`rw_file_perms', `{ r_file_perms w_file_perms }')
define(`rwx_file_perms', `{ rw_file_perms x_file_perms }')
define(`create_file_perms', `{ create rename setattr unlink rw_file_perms }')
Am I missing something very obvious here?

I have had a similiar issue and belief I have the solution to your problem.
Posting it here, even if your question is quiet old at this point so that others having the same problem may be helped.
The issue is that untrusted apps also have a MSL tag your avc error:
scontext=u:r:untrusted_app:s0:c512,c768
Notice that after the "normal" se-linux staff you have :c512,c768, this seems to be a MLS "tag".
Your untrusted_app.te/tty_device does not handle this - as usual in SELinux by default the app is not allowed to access objects, even though the rest of the rule is ok.
You have three options at this point:
Write rules which allows MLS tagged subjects to your device
Write rules which targets your app and strips the MLS tag
Write rules which leaves the MLS tag but allows access to the device. (Probably the most secure)
I went the first (1) way and added two files under device/manufacturer/device/sepolicy:
file_contexts
/dev/ttyHSL1 u:object_r:arendi_device:s0
serialports.te
type arendi_device, dev_type, mlstrustedobject;
allow untrusted_app_all arendi_device:chr_file rw_file_perms;
Notice the mlstrustedobject tag - this tells SEAndroid that it should ignore MLS tags from subjects wanting access to this label.
There's also mlstrustedsubject which you could add to your app by rules.
My BoardConfig.mk tells Android to look for these new files by adding this line:
BOARD_SEPOLICY_DIRS += device/manufacturer/device/sepolicy
This now allows me access to my serialport under Android Oreo 8.1.
This answer pointed me to this solution:
My custom selinux policies seem to be ignored by android system

insmod in android lollipop with SE Linux enforced

I am trying to perform insmod abc.ko with a few module params,
However these module params need to be dynamically computed. So I am launching an app /system/bin/my_app to compute these params and then perform insmod within my_app.
Issue:
When my_app is launched at bootup using init.hammerhead.rc script, it is unable to perform insmod and give following error
type=1400 audit(0.0.4): avc: denided {sys_module} for path="system/bin/my_app" dev="mmcblk0p25" ino=170 scontext=u:r:init:s0 tcontext=u:r:init.s0 tclass=file
How can i enable my_app to be able to insmod ?
Would appreciate any pointers to resolve this

The ability to insmod a module is linked with the permissions of the code running do_insmod(). In your case, the issue is that there is no policy described that allow your sw to access the module.
I am not expert in sepolicy but there is a why to generate the appropriate policy file from the logs : here is a good article about that : https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/Security-Enhanced_Linux-The-sepolicy-Suite-sepolicy_generate.html
Hope that helps.
Aymen.

Finally found a solution.
my_app should be given new policies which allow it to perform insmod.
[1] Create my_app.te in ///sepolicy/my_app.te
[2] Add the following policies to my_app.te .
type my_app, domain;
type my_app_exec, exec_type, file_type;
allow my_app self:capability sys_module;
allow my_app self:capability { setuid setgid };
allow my_app self:capability sys_admin;
allow my_app shell_exec:file rx_file_perms;;
init_daemon_domain(my_app)
permissive_or_unconfined(my_app)
[3] Add my_app.te to BOARD_SEPOLICY_UNION in BoardConfig.mk file.
[4] Add following to sepolicy/file_contexts
/system/bin/my_app u:object_r:my_app_exec:s0
For further info or issue : subscribe to seandroid-list-join#tycho.nsa.gov