Develop Reference

/sys/fs/pstore won't work on poco m3 android, is there a way to fix it?

I'm trying to use pstore logs on my Poco M3. I tried everything. PSTORE configs are activated on the kernel, pstore module is loaded on the phone, phone is rooted, /sys/fs/pstore is mounted automatically but never contains anything.
130|citrus:/ # dmesg | grep pstore
[ 0.094327] console [pstore-1] enabled
[ 0.094468] pstore: Registered ramoops as persistent store backend
[ 1.065975] pstore: Using compression: deflate
[ 98.052156] type=1400 audit(1654268897.690:3752): avc: denied { read } for comm="ls" name="/" dev="pstore" ino=1197 scontext=u:r:shell:s0 tcontext=u:object_r:pstorefs:s0 tclass=dir permissive=1
[ 98.052450] type=1400 audit(1654268897.690:3753): avc: denied { open } for comm="ls" path="/sys/fs/pstore" dev="pstore" ino=1197 scontext=u:r:shell:s0 tcontext=u:object_r:pstorefs:s0 tclass=dir permissive=1
it looks like selinux is blocking ls on /sys/fs/pstore. Is there a way to make it always allow ls on /sys/fs/pstore, even after reboot?
I already added androidboot.selinux=permissive to my boot command line and it's recognized on the phone:
130|citrus:/ # getenforce
Permissive
UPDATE: I just learned that permissive means just logging without blocking, so this is not blocking, my pstore is indeed empty. Am I right?

/sys/fs/pstore is used very specifically - to persistently store crash files - kernel oops and last RAM console. So the fact it doesn't contain anything is actually good, in a way.
To see for yourself - simulate a panic. That'd require writing 'c' to /proc/sysrq_trigger (and possibly enabling that via /proc/sys/kernel/sysrq mask). The device will reboot, and on the boot you will see that the store files appear. (Note this has to be the boot immediately following the crash, because the files are cleared thereafter.
Incidentally - Re:SELinux , those AVC logs you showed are because SELinux denied the "ls" operation itself. That is a mandatory access control protection, which prevents reading the directory (even when it is empty). So that wouldn't change much.

avc: denied { connectto } when using uds on Android 10

I'm running 2 applications on Android 10 device which communicate each other via uds. Everything worked fine until I changed the apps settings to target android 10. I get following error in logcat:
09-07 13:33:18.136 14573 14573 W <myapp_name>: type=1400 audit(0.0:1461891): avc: denied { connectto } for pid=14573 comm=474C546872656164203134353530 path=005368617265644D656D6F727953657276696365 scontext=u:r:untrusted_app_27:s0:c512,c768 tcontext=u:r:untrusted_app_25:s0:c512,c768 tclass=unix_stream_socket permissive=0
After some digging I found neverallow SELinux policy:
neverallow { all_untrusted_apps -mediaprovider } init:unix_stream_socket connectto;
Is there a way I can make it work on applications targeting Android 10?

UDS with abstract path doesn't work for API>=28 due to the following changes.
Per-app SELinux domains
Apps that target Android 9 or higher cannot share data with other apps using world-accessible Unix permissions. This change improves the integrity of the Android Application Sandbox, particularly the requirement that an app's private data is accessible only by that app.
To share files with other apps, use a content provider.
https://developer.android.com/about/versions/pie/android-9.0-changes-28#framework-security-changes

Android is disallowing execution of native library when running as system app

When I sign my app with the system certificate, I can no longer use an SDK that comes with a custom native library. The SDK executes code from that native library. All works fine when my app is not signed as a system app, but when signed, I get an error.
The error appears to come from an SELinux policy with this log message:
type=1400 audit(0.0:22): avc: denied { execute } for
comm=4173796E635461736B202331
path="/data/data/myapp/cache/librs.bitmap_to_argb.so" dev="mmcblk0p22"
ino=16791 scontext=u:r:system_app:s0
tcontext=u:object_r:system_app_data_file:s0 tclass=file permissive=0
Why would my app not be able to execute a library like this that is located in the app's internal storage?

System apps expect their native libraries to be in /system/lib or lib64 directory. Maybe you can avoid this if you set android:extractNativeLibs="false" in the application manifest.

Permission denied error when opening /proc/<PID>/stat file

I wrote a daemon, running as system.
When it tries to open some /proc//stat entry of process PID which using its library, I get this error of SELinux:
type=1400 audit(1464247244.561:530): avc: denied { search } for pid=22968 comm="Binder_3" name="22899" dev="proc" ino=71342 scontext=u:r:system_app:s0 tcontext=u:r:untrusted_app:s0:c512,c768 tclass=dir permissive=0
Do I miss some “allow” rule to my daemon?
The error seems unrelated to it (as if ‘system_app’ domain lack permissions, and not my daemon).
How can I fix it?

You should execute
adb shell ps -eZ | grep 22968
command to find the problematic service or app from command line as your app running at the same time. After you find the victim(app) you have to add /external/sepolicy/service_contexts file a SELinux rule for handling the access violation.

Unable to boot freshly built CyanogenMod 13

After playing around with the latest build of CM for my device (12.1), I decided to try and build my first ROM. So I got Linux, synced sources for 13, etc. (My device tree is here.)
I had to grapple with a few audio-related build errors before I finally got it to build. (If it makes any difference, all the commits I had to revert were related to PCM audio offloading.)
Now, when I try to boot the ROM, it immediately reboots to recovery without even displaying the boot animation. Looking at /proc/last_kmsg, the problem seems to be about SELinux:
...
[ 4.340084] init: (Initializing SELinux enforcing took 0.51s.)
[ 4.349071] type=1400 audit(1468237723.015:4): avc: denied { fowner } for pid=1 comm="init" capability=3 scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 tclass=capability permissive=0
[ 4.349387] init: SELinux: Could not set context for /init: Operation not permitted
[ 4.349506] init: restorecon failed: Operation not permitted
[ 4.349699] init: Security failure; rebooting into recovery mode...
[ 4.350353] SysRq : Emergency Remount R/O (triggered by init:1)
[ 4.350581] Emergency Remount complete
[ 4.350889] reboot - triggered with task: init (1:1)
...
I'm not familiar with SELinux apart from the fact that it makes system modifications a lot harder, but from what I've seen, both the device-specific and general init.te files in the Android source allow init to use the fowner capability.
I've tried:
Modifying the sepolicy file by making the init domain permissive
Rebuilding the entire ROM with permissive init; in init.te
Commenting out restorecon /adb_keys and restorecon_recursive /mnt in init.rc
Rebuilding the device kernel with EXTRA_CFLAGS += -DCONFIG_ALWAYS_ENFORCE=true
Searching for a solution on Google - a person on XDA had the exact same problem as me but subsequent posts from him/her did not yield any progress or solutions on the matter
None of them made any difference, so basically, I'm fresh out of ideas.
What am I doing wrong?