SELinux needs to be disabled to make nexutil work on new devices

[matthiasseemoo]

trafficstars

Nexutil sends ioctls to the bcmdhd driver that forwards those to the Wi-Fi firmware and delivers the result back to nexutil. The same is true for libnexmon.so. On older devices, only root permissions were needed to get nexutil to work. However, on newer devices, such as the Galaxy S10 and S20, SELinux hinders root users to send ioctls to the bcmdhd driver in the kernel. Disabling SELinux allows nexutil to work again, however, this generally requires a rebuild of the kernel. I would like to reconfigure SELinux in a way to allow the root user to send ioctls. Any solutions for this problem would be appreciated.

[KuLiD]

The SElinux applies to the S8+ aswell, I dont know about any other users but I have that problem. Kernel rebuild is the only solution I have seen so far.

[ghost]

@KuLiD Kernel rebuild might indeed be the only solution. Samsung's stock kernel has SELinux as always enforcing and on new Samsung devices such as S10 and S20 the kernel image resides in boot/recovery (depends on whichever you're booted from). This means you will end up with enforcing SELinux even if you disable or try to keep it disabled in userspace unless you swap the boot image. I think someone has tried to hex patch some related binaries years ago but so far there's no progress.

[davidrozen76]

Magisk root allows modification of the SELinux policy, which in turn permits the root user to send ioctls.

In this way, SELinux needs not to be disabled, otherwise having a modified policy.

[KuLiD]

@davidrozen76 Hi there, are you referring to the method where one actually goes into the file tree and modifies the policy??....its doesnt work, i have tried it unless you are referring to another method....

[ghost]

Magisk root allows modification of the SELinux policy, which in turn permits the root user to send ioctls.

In this way, SELinux needs not to be disabled, otherwise having a modified policy.

I'm not sure I fully understand what you're saying as I don't recall Magisk itself being able to change SEL status. Yes you could change SEL manually provided your kernel was compiled to allow it with root in userspace but many other OEMs like Samsung compiled their kernel such that SEL will always be enforcing.

Without going into the technicalities here's something you could easily try yourself and see what we mean:

Flash a stock boot image/kernel -> Root with Magisk -> Run ifconfig in a root shell, fails + SEL status reports enforcing Flash a modified kernel w SEL disabled -> Root with Magisk -> Run ifconfig in a root shell, succeeds + SEL status permissive

[ghost]

Magisk root allows modification of the SELinux policy, which in turn permits the root user to send ioctls.

In this way, SELinux needs not to be disabled, otherwise having a modified policy.

As you're trying the procedure above feel free to use setenforce or whatever other userspace methods to switch SEL status - these won't work on the latest Samsung devices, and this is what this issue is about.

[davidrozen76]

Magisk root allows modification of the SELinux policy, which in turn permits the root user to send ioctls. In this way, SELinux needs not to be disabled, otherwise having a modified policy.

As you're trying the procedure above feel free to use setenforce or whatever other userspace methods to switch SEL status - these won't work on the latest Samsung devices, and this is what this issue is about.

Yeh I was just implying this as an alternative. There are plenty of tutorials out there on how to configure and compile a custom kernel with SELinux set to permissive, which, I can confirm, works like a charm.

[davidrozen76]

Magisk root allows modification of the SELinux policy, which in turn permits the root user to send ioctls. In this way, SELinux needs not to be disabled, otherwise having a modified policy.

I'm not sure I fully understand what you're saying as I don't recall Magisk itself being able to change SEL status. Yes you could change SEL manually provided your kernel was compiled to allow it with root in userspace but many other OEMs like Samsung compiled their kernel such that SEL will always be enforcing.

Without going into the technicalities here's something you could easily try yourself and see what we mean:

Flash a stock boot image/kernel -> Root with Magisk -> Run ifconfig in a root shell, fails + SEL status reports enforcing Flash a modified kernel w SEL disabled -> Root with Magisk -> Run ifconfig in a root shell, succeeds + SEL status permissive

see magiskpolicy

[ghost]

@

Magisk root allows modification of the SELinux policy, which in turn permits the root user to send ioctls. In this way, SELinux needs not to be disabled, otherwise having a modified policy.

I'm not sure I fully understand what you're saying as I don't recall Magisk itself being able to change SEL status. Yes you could change SEL manually provided your kernel was compiled to allow it with root in userspace but many other OEMs like Samsung compiled their kernel such that SEL will always be enforcing. Without going into the technicalities here's something you could easily try yourself and see what we mean: Flash a stock boot image/kernel -> Root with Magisk -> Run ifconfig in a root shell, fails + SEL status reports enforcing Flash a modified kernel w SEL disabled -> Root with Magisk -> Run ifconfig in a root shell, succeeds + SEL status permissive

see magiskpolicy

Ok this is enough. I'm not sure we're on the same page. Everyone in this thread knows magiskpolicy exists AND if you have root you could tweak SEL in the userspace through modifying sepolicy + use setenforce + whatever userspace method leveraging root, PROVIDED your kernel was configured to allow such modifications.

There are by and large three categories of kernel implementations regarding SEL by OEMs: A. enforce by default, allow status switching in userspace -> what most devices use, usually older ones B. always enforce, regardless what the userspace implementation is -> what newer devices use, incl. the Samsung models mentioned in this thread C. always permissive, regardless what the userspace implementation is -> custom kernels

I am fairly sure what you're referring to applies to category A devices, which, needless to say works on OEM kernel as long as you have root. The devices we were referring to are category B and what we aim to achieve is C. I am not sure why you were messing with your kernel if you could already achieve SEL in userspace. I hope this clarifies your confusion.

[davidrozen76]

@

Magisk root allows modification of the SELinux policy, which in turn permits the root user to send ioctls. In this way, SELinux needs not to be disabled, otherwise having a modified policy.

I'm not sure I fully understand what you're saying as I don't recall Magisk itself being able to change SEL status. Yes you could change SEL manually provided your kernel was compiled to allow it with root in userspace but many other OEMs like Samsung compiled their kernel such that SEL will always be enforcing. Without going into the technicalities here's something you could easily try yourself and see what we mean: Flash a stock boot image/kernel -> Root with Magisk -> Run ifconfig in a root shell, fails + SEL status reports enforcing Flash a modified kernel w SEL disabled -> Root with Magisk -> Run ifconfig in a root shell, succeeds + SEL status permissive

see magiskpolicy

Ok this is enough. I'm not sure we're on the same page. Everyone in this thread knows magiskpolicy exists AND if you have root you could tweak SEL in the userspace through modifying sepolicy + use setenforce + whatever userspace method leveraging root, PROVIDED your kernel was configured to allow such modifications.

There are by and large three categories of kernel implementations regarding SEL by OEMs: A. enforce by default, allow status switching in userspace -> what most devices use, usually older ones B. always enforce, regardless what the userspace implementation is -> what newer devices use, incl. the Samsung models mentioned in this thread C. always permissive, regardless what the userspace implementation is -> custom kernels

I am fairly sure what you're referring to applies to category A devices, which, needless to say works on OEM kernel as long as you have root. The devices we were referring to are category B and what we aim to achieve is C. I am not sure why you were messing with your kernel if you could already achieve SEL in userspace. I hope this clarifies your confusion.

As you were saying, setenforce 0 on newer devices does not change SELinux to permissive.

And yes, I achieved SELinux always permissive using a custom kernel on both the S10 and S20.

[matthiasseemoo]

There is a potential alternative but it would need some time to investigate. With nexmon, we always tried to avoid kernel changes, we always wanted to provide a solution where one only has to replace the firmware file. That worked so far for bcmdhd driver based devices and still works as long as you do not want to call ioctls, which is what you do using nexmon.

There are two possible solutions that come to my mind:

1. Send the information from the ioctls over a different path to the wifi chip. For example, over UDP. We already demonstrated this on SDIO based devices, however, it gets more complex on PCIE based devices as only partical frames end up in the ARM firmware and the rest goes directly to the frame buffers of the D11 core.
2. There is shared memory between WiFi part and Bluetooth part of the chip. One could use this to send ioctls over the Bluetooth firmware to the WiFi firmware. Maybe it would even allow to load a complete WiFi firmware over the Bluetooth chip. If there were any students around who would like to work on this topic, please let me know.

On 27. May 2021, at 13:21, davidrozen76 @.***> wrote:

@

Magisk root allows modification of the SELinux policy, which in turn permits the root user to send ioctls. In this way, SELinux needs not to be disabled, otherwise having a modified policy.

I'm not sure I fully understand what you're saying as I don't recall Magisk itself being able to change SEL status. Yes you could change SEL manually provided your kernel was compiled to allow it with root in userspace but many other OEMs like Samsung compiled their kernel such that SEL will always be enforcing. Without going into the technicalities here's something you could easily try yourself and see what we mean: Flash a stock boot image/kernel -> Root with Magisk -> Run ifconfig in a root shell, fails + SEL status reports enforcing Flash a modified kernel w SEL disabled -> Root with Magisk -> Run ifconfig in a root shell, succeeds + SEL status permissive

see magiskpolicy

Ok this is enough. I'm not sure we're on the same page. Everyone in this thread knows magiskpolicy exists AND if you have root you could tweak SEL in the userspace through modifying sepolicy + use setenforce + whatever userspace method leveraging root, PROVIDED your kernel was configured to allow such modifications.

There are by and large three categories of kernel implementations regarding SEL by OEMs: A. enforce by default, allow status switching in userspace -> what most devices use, usually older ones B. always enforce, regardless what the userspace implementation is -> what newer devices use, incl. the Samsung models mentioned in this thread C. always permissive, regardless what the userspace implementation is -> custom kernels

I am fairly sure what you're referring to applies to category A devices, which, needless to say works on OEM kernel as long as you have root. The devices we were referring to are category B and what we aim to achieve is C. I am not sure why you were messing with your kernel if you could already achieve SEL in userspace. I hope this clarifies your confusion.

As you were saying, setenforce 0 on newer devices does not change SELinux to permissive.

And yes, I achieved SELinux always permissive using a custom kernel on both the S10 and S20.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/seemoo-lab/nexmon/issues/471#issuecomment-849551303, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACZ773UAZCEFXBQPFEBIWXDTPYTLVANCNFSM42RSVEWQ.