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
Related
i have a bespoke deamon i am adding to my android 8.1 source tree.
but i keep getting the error:
type=1400 audit(21.610:3): avc: denied { transition } for pid=217 comm="init" path="/system/bin/rfidmanagerd" dev="dm-1" ino=293 scontext=u:r:init:s0 tcontext=u:object_r:rfidmanager_exec:s0 tclass=process permissive=1
here is my rfidmanager.te file:
# RFID manager process
type rfidmanager, coredomain;
type rfidmanager_exec, exec_type, file_type;
init_daemon_domain(rfidmanager)
domain_auto_trans(init, rfidmanager_exec, rfidmanager)
# Access system/etc/rfid
allow rfidmanager sysfs:file rw_file_perms;
allow rfidmanager tmpfs:chr_file { read write };
allow rfidmanager sysfs:file write;
allow rfidmanager system_file:file r_file_perms;
# Access /data/misc/rfid.
allow rfidmanager misc_rfid_file:dir create_dir_perms;
allow rfidmanager misc_rfid_file:file create_file_perms;
allow rfidmanager misc_rfid_file:file rw_file_perms;
allow rfidmanager misc_rfid_file:file { read write setattr append unlink link rename };
allow rfidmanager misc_rfid_file:fifo_file { create open read write };
# Access /dev/circchar
allow rfidmanager rfidhal_device:chr_file r_file_perms;
allow rfidmanager rfidhal_device:chr_file { read write };
# Access serial ports
allow rfidmanager tty_device:chr_file r_file_perms;
here is my file_contexts:
/system/bin/rfidmanagerd u:object_r:rfidmanager_exec:s0
in my init.te file for the denial i have :
allow init rfidmanager_exec:process {transition};
the device needs to have SELinux on enforcing mode. and here is how i start my service in the init.rc file
service rfidmanagerd /system/bin/rfidmanagerd -c /system/etc/rfid/rfidmanagerd.conf
class core
seclabel u:object_r:rfidmanager_exec:s0
user root
group root system
oneshot
start rfidmanagerd
when i try and start the service manually i.e
su system
./system/bin/rfidmanagerd
it starts, but using ps -eZ i see the service is as follows:
u:r:su:s0 system 859 1 4524 360 poll_schedule_timeout 0 S rfidmanagerd
it should however be with the u:object_r:rfidmanager_exec:s0 as i have defined in my contexts.
it does not start automatically which is understandable via the SELinux denial error, however any combination of allow rules for this particular denial seem to be ignored.
when i try and do start rfidmanagerd (as root)in the terminal i get
[ 474.879385] init: starting service 'rfidmanagerd'...
[ 474.885868] init: property_set("ro.boottime.rfidmanagerd", "474879774055") failed: property already set
[ 474.915929] init: cannot execve('/system/bin/rfidmanagerd'): Permission denied
[ 474.925563] type=1400 audit(480.580:9): avc: denied { transition } for pid=998 comm="init" path="/system/bin/rfidmanagerd" dev="dm-1" ino=381 scontext=u:r:init:s0 tcontext=u:object_r:rfidmanager_exec:s0 tclass=process permissive=0
I understand the denial, but dont understand why my allow rule is not fixing this...
everything runs fine when i am in permissive mode, but as i said i cannot have it in permissive.
Any help would be greatly appreciated!
Thanks
UPDATE -- I HAVE HAD THIS MIGRATED FROM ANDROID ENTHUSIASTS TO STACKEXCHANGE BACK TO ANDROID ENTHUSIASTS - it keeps getting moved, can someone please help me!
for anyone who is having a similar issue....Android 8.1 needs the coredomain to not have a neverallow rule, when compiling the selinux!
However, this has some issues with selinux resolving the setexeccontext.
so the first line in my .te file should read -
type rfidmanager, coredomain, domain;
instead of just
type rfidmanager, coredomain;
i hope this helps anyone.
Hope this will help somebody to save time in future.
You should use this secable in service definition:
seclabel u:r:rfidmanager:s0
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.
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.
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
I recently tried to read a file /system/bin/debuggerd in Android.I can install app or use adb commands but this error:
Unfortunately I was denied by SELinux
[105336.331813] type=1400 audit(8732769.717:226): avc: denied { read } for pid=17773 comm="ServiceHandlerB" name="debuggerd" dev="dm-0" ino=279 scontext
=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:debuggerd_exec:s0 tclass=file permissive=0
I can't root this device by rule,so is it possible to read this file?
this troubles me for a whole day,thx for help.
If you can't 'root' the device, than no.
The details are as follows. debuggerd_exec file is declared as:
type debuggerd_exec, exec_type, file_type;
This means that a processes attempting to read the file would need read permission on either the type debuggerd_exec or on the attributes exec_type or file_type.
Using the current tip of AOSP master at the time of this reply and the lunch target aosp_x86_64-eng, we can see what "source domains" can actually read this file with the following sesearch command:
$ sesearch -A -t debuggerd_exec -c file -p read $OUT/root/sepolicy
allow debuggerd debuggerd_exec:file { read open getattr entrypoint execute };
allow debuggerd exec_type:file { read lock ioctl open getattr };
allow init debuggerd_exec:file { read getattr open execute };
allow perfprofd exec_type:file { read lock ioctl open getattr };
If you notice the source domains (the first thing after the allow), none of them are shell or untrusted_app. On non-rooted user builds, without an exploit, one can only run code in the untrusted_app or shell domains (that isn't exactly true, but the details are not really important).
Additionally, even if untrusted_app did have access, you need to be aware that MLS can sometimes prevent access even when sesearch shows that you have access. SE Linux on Android is using both Type Enforcement (allow rules) and MLS (mls_constrain rules) to provide isolation and sandbox reinforcement.