ExFAT thumb drives do not work on OxygenOS, upon insertion you're asked to reformat the drive.
It turns out that ExFAT support is built in (at least since OOS 9), but a bug in the OOS SELinux policies shipped with the device prevents ExFAT from working.
This module patches the SELinux policy with Magisk and allows ExFAT-formatted drives to work.
It does the equivalent of running this root command:
supolicy --live 'allow fsck_untrusted system_file file { entrypoint }
Tested on:
- OnePlus 8T running OOS 11.0.8.13
- OnePlus 7Pro running OOS 9.5.13
Related
As the title suggests, I'm attempting to compile a (Lollipop) Nexus 5 kernel with SELinux in permissive mode by default. For reference, I am using the msm kernel source tree at commit 8a80a0e.
I have managed to accomplish this by modifying msm/security/selinux/selinuxfs.c and inserting new_value = 0; into sel_write_enforce to prevent the mode being changed:
Code:
length = -EINVAL;
if (sscanf(page, "%d", &new_value) != 1)
goto out;
new_value = 0; /* inserted this line */
if (new_value != selinux_enforcing) {
length = task_has_security(current, SECURITY__SETENFORCE);
if (length)
goto out;
audit_log(current->audit_context, GFP_KERNEL, AUDIT_MAC_STATUS,
"enforcing=%d old_enforcing=%d auid=%u ses=%u",
This method, however, doesn't seem particularly good, as it relies on the intricacies of the specific implementation of SELinux used in this kernel, and prevents the mode being changed later.
This post suggests changing the CONFIG_ALWAYS_ENFORCE flag for a Samsung device, however the Nexus 5 kernel does not appear to have such an option. Setting the default state of SELinux using various menuconfig options and kernel command line parameters does not appear to have any effect, and disabling it entirely causes the device to crash after boot, before any logcat output is produced.
I have noticed than when started with a kernel with SELinux enabled, one of the first messages from logcat is from auditd, of the form enforcing=1 old_enforcing=0 auid=... ses=..., indicating that something is setting the SELinux mode to enforcing almost immediately after boot.
Thus, I am wondering if anyone knows where this command to set SELinux to enforcing comes from, how to disable it, or another way to compile a kernel with SELinux set to permissive?
I believe you need to change the kernel config to allow command line switching of SELinux:
Code:
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
then modify the boot parameters of your boot.img adding to the cmdline:
Code:
enforcing=0 androidboot.selinux=permissive
I think that's the way. I went through all this but ended up just disabling SELinux altogether so I can't remember for sure if that's all.
Gene Poole said:
I believe you need to change the kernel config to allow command line switching of SELinux:
Code:
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
then modify the boot parameters of your boot.img adding to the cmdline:
Code:
enforcing=0 androidboot.selinux=permissive
I think that's the way. I went through all this but ended up just disabling SELinux altogether so I can't remember for sure if that's all.
Click to expand...
Click to collapse
Doesn't work. The system boots up in permissive mode, but immediately switches to enforcing, as it usually does. The first few lines of logcat:
Code:
--------- beginning of main
I/installd( 0): installd firing up
W/auditd ( 169): type=2000 audit(0.0:1): initialized
I/auditd ( 169): type=1403 audit(0.0:2): policy loaded auid=4294967295 ses=4294967295
W/auditd ( 169): type=1404 audit(0.0:3): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295
Are you using the google boot image, or the AOSP image (they're quite different)? I just checked mine (built from source) and init has -DALLOW_DISABLE_SELINUX=1 which may not be present in the distro version of init.
Gene Poole said:
Are you using the google boot image, or the AOSP image (they're quite different)? I just checked mine (built from source) and init has -DALLOW_DISABLE_SELINUX=1 which may not be present in the distro version of init.
Click to expand...
Click to collapse
I wasn't aware there was a difference. I compiled the kernel from source, enabling the relevant config options, then got boot.img from the Nexus 5 factory image, and extracted and replaced the kernel and boot parameters as suggested by this document.
The boot.img built as part of the AOSP build (with USERDEBUG flag) is not locked down the way the factory boot image is. There may be something built-in to the init process to ensure selinux is available in the kernel and cannot be disabled.
I wish I knew more about this. My original goal was to implement the things I needed in the AOSP build and set up selinux permissions to allow it, but I gave up and ended up just removing selinux from the kernel altogether.
Hmm... I'll take a look in the initrd of the Android boot images to see if there's anything in there that might be setting the SELinux mode.
Update: Bah. It seems the AOSP source of init can be configured to accept a ro.boot.selinux parameter, but I see no indication that the code is present in the stock init binary. The code also explains why the phone immediately reboots into recovery when SELinux support is disabled in the kernel.
Update 2: After attempting to download 18GB of AOSP source code, I think my dodgy way of disabling SELinux is really the best method.
Gene Poole said:
I believe you need to change the kernel config to allow command line switching of SELinux:
Code:
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
then modify the boot parameters of your boot.img adding to the cmdline:
Code:
enforcing=0 androidboot.selinux=permissive
I think that's the way. I went through all this but ended up just disabling SELinux altogether so I can't remember for sure if that's all.
Click to expand...
Click to collapse
bootloop ¯\_(ツ)_/¯
Just disable it in the config?
Why do you need it if you don't use it?
Jo_Jo_2000 said:
Just disable it in the config?
Why do you need it if you don't use it?
Click to expand...
Click to collapse
I prefer CONFIG_ALWAYS_ENFORCE = false instead of new_value = 0
Hello again!
Tried launching supolicy --live as root in init context, it failed with code -13.
What gives? If I want to run supolicy --live very early in init, which context should I use ? Should I assume Zygote's context via seclabel ?
Hey, I hope I will not be comitting a gross transgression if I tag @Chainfire into this to hopefully draw attention.
Basically, what I'm trying to do is to patch Selinux policies and temporarily set Selinux to Permissive rather early during init sequence (after /system is available but before /data is properly available)
Supolicy --live says
supolicy v2.45 (ndk:arm64-v8a) - Copyright (C) 2014-2015 - Chainfire
Patching policy ...
- Failure! 13
Click to expand...
Click to collapse
What has gone wrong and how would I go about making it right ?
P.S.:
Do note that when the boot completes Supersu runs fine and Selinux can be switched to Permissive without issue (but it's too late at that point )
Android is Lollipop 5.0 and sources are not available for this specific ROM
Hello,
I tried on
supolicy v2.64 (ndk:armeabi-v7a)
same problem. Did you find a way to fix this issue ?
Error 13 is access denied. supolicy probably doesn't have the rights to read/write the sepolicy.
I just tried installing Magisk v9 with the current Xposed module on a YotaPhone 2 running Android 5.0, but it seems that the module doesn't correctly initialize.
I downloaded and installed the Xposed SDK 21 module in Magisk Manager v2.5. After reboot, however, the module list in Magis Manager was empty (not even phh's Superuser was visible there, which I previously flashed in recovery). However, the Magisk log shows that the Xposed script is executed:
Code:
** Magisk post-fs mode running...
** Magisk post-fs-data mode running...
Preparing modules
Bind mount dummy system
Bind mount module items
post-fs-data: /magisk/xposed/post-fs-data.sh
Enabling systemless hosts file support
Mount: /magisk/.core/hosts
Bind mount system mirror
Mount: /system
Bind mount mirror items
** Magisk late_start service mode running...
service: /magisk/phh/service.sh
phh: Live patching sepolicy
phh: Mounting supath
phh: Starting su daemon
The Xposed Installer now shows on the status screen that Xposed is installed but not active. An Xposed log file in /data/data/de.robv.android.xposed.installer/log doesn't exist. Logcat has no entries for Magisk nor Xposed. Also, the "Enable systemless hosts" checkbox in Magisk Manager isn't active anymore after reboot, even if it clearly is configured that way according to the logs. Is this a bug in Magisk or am I doing something wrong?
Hi everybody,
I just installed lineageOS 15.1 yesterday (first time rooting a phone and changing the OS) on my Nexus 6 and I would like to enableAPTX also. However, I am not sure which file to flash; the regular one, the hd, the hd-system or the oreo? (https://forum.xda-developers.com/oneplus-3/themes/mod-aptx-codec-t3521228/post70139848#post70139848).
Any ideas? Also, what happen if you flash the wrong file on your phone?
Thanks in advance,
Little update, I did flash the oreo file yesterday and aptx is now working on the phone. You can see the codex being used in Catlog and in the developer options.
Hi all!
Unfortunately I was not that lucky to have my AptX start OOTUZ (Out of the update zip ).
Hopefully this might help others. I have found no real solution.
So I had my Nexus 6 switched to Official LineageOS 15.1 nightly (2018 Aug. 21.) (Official has SELinux set to Enforcing!!) and wanted AptX enabled (Not AptXHD).
I had the "APTX-enabler.zip - [Click for QR Code] (114.1 KB, 1600 views) from https://forum.xda-developers.com/apps/magisk/port-aptx-aptxhd-oreo-8-0-update-jan-t3731151" update flashed through TWRP, but running CatLog , with root permission, revealed an AVC denial (Start catlog, connect bt, pause catlog,search for "apt", open red Errors, hopefully find AVC denial and nothing else) .
SElinux blocked the acces to the file as it had default security context. To test I issued
Code:
#setenforce permissive
from root cli (I used Terminal Emulator) and checked if really SELinux is the "culprit". It was. AptX worked like a charm. So lets try it with correct context.
I have remounted the system partition to be writable:
Code:
#mount -o remount -o rw /system
and set the lib's type context to the following:
Code:
#chcon u:object_r:vendor_file:s0 /system/vendor/lib/libaptX_encoder.so
Works for now even after reboot obviously. (Till next nightly or till some script screws it up?)
Let's undo the mess. Readonly system FS:
Code:
#mount -o remount -o ro /system
Set back SELinux:
Code:
#setenforce enforcing
Or just reboot.
Can someone help me with this error?
Overlay permission is already checked...
Code:
04-23 21:34:41.328 9075 9075 W GH.PermissionChecker: Overlay permission denied: android.view.WindowManager$BadTokenException: Unable to add window [email protected] -- permission denied for window type 2010
04-23 21:34:41.432 9075 9075 W GH.PermissionChecker: Overlay permission denied: android.view.WindowManager$BadTokenException: Unable to add window [email protected] -- permission denied for window type 2010
04-23 21:34:41.537 9075 9075 W GH.PermissionChecker: Overlay permission denied: android.view.WindowManager$BadTokenException: Unable to add window [email protected] -- permission denied for window type 2010
I'm encountering this problem too, on a Redmi Note 2. The Android Auto check won't see that I ticked the Overlay permission.
I know this thread is quite old, but I figured out that the issue is in the current Android Auto app.
AA tries the wrong method to request overlay permission.
That's because it checks the Android version in the ROM signature (ro.build.fingerprint).
Most of custom ROMs keep the original phone signature to preserve Android CTS although they upgrade the Android OS version.
As an example, for Redmi4X, the latest lineageos version available is 16.0 (Android 9), but the ROM signature inside is still "santoni-user 7.1.2 N2G47H V9.2.1.0.NAMCNEK release-keys".
AA catches "7.1.2" and believes it is on Android Nougat whereas the system is Pie.
Overlay permission request is different between Nougat and Pie, AA calls the wrong methods, leading to this "permission denied".
Workarounds are:
- change your /system/build.prop, changing ro.build.fingerprint to avoid the pattern "7.1.2", but you will loose CTS
- Use Magisk SafetyPatch v3 as proposed here (this modifies the fingerprint+security patch to a newer version, in order to keep CTS)
- spoof build fingerprint like done here , but for "com.google.android.projection.gearhead" (package name for AA).