Sounds like a pain

Only of you want to. my comment is open source.

• under MIT licence.

More than once, now that I think about it

I might get down voted for this, but I've honestly found LLMs pretty useful tools for debugging SELinux.

selinux relies on the basis of deny all, allow only ideas

Only in enforced.

but when you are troubleshooting issues, ,

Just set setenforce 0 for this

installing software or developing applications

for this see policy log and create selinux policy with generator if developer was lazy

it can hinder productivity by preventing the user from doing things

Highter productivicy before someone still all your code (like binance)

I wish I could set up SELinux but NixOS doesn't support it... I already do something similar where all files on root are wiped by default (E: on each boot) and I have to opt things into persistence so it's definitely something that I'd like.

git gud

While the stock policies have been refined to model more of an average user's usage, the facility itself remains a PITA when people do trip over it. File operations that mess up contexts, use cases that don't quite fit the policy, use cases that are well recognized but SELinux blocks it by default anyway until you change an sebool.

By being a security mechanism bolted on after the fact, various operations fail in ways that are mysterious because they can't inject explanatory information into the failure path. Further the audit log that you pretty much always need to consult when something fails for mysterious reasons in case it might be SELinux isn't even readable by the user that got dinged. So I can't even code in a way to check if SELinux was the reason and guide the user, instead I have to provide a diagnostic utility they have to 'sudo' to explain to them, or be vague and say 'check if selinux is somehow involved. So I end up despite doing my damndest to not run with privilege asking users to run something with privilege to check a security mechanism.

The existence and usage of audit2allow is a big sign of problematic design. How to fix something you see in auditlog is hard for people to understand, so they just audit2allow to amend policy, but instead they should have done a chcon because now they have a crap rule allowing something they shouldn't, but SELinux is still enabled so all good!

The whole label based concept is a fun whole other dimension of things for people to worry about. Messed up so often that we have a nice convenient 'restorecon' to basically apply the way AppArmor does things to the filesystem in that moment.

The curve could follow someone's journey with complexity, starting out with the prejudice that SELinux is bad, then letting SELinux happen and noticing no issues, and then moving on to realms where they actually have to touch the goop of SELinux instead of the canned distro SELinux setup covering their use case.

tenet

no, not really. you wouldn't be allowed to disable it then.

SELinux is a critical part of the least privilege model of a Android system. It is why Android hasn't been impacted by almost all Linux CVEs. Unlike desktop Linux, Android was created after modern security threats were around. Overtime the system has been partitioned so that a compromise in ome area doesn't impact others. It isn't flawless but it does a pretty good job.

Don't disable SELinux

It breaks the entire Android security model. Your device will become highly vulnerable as apps will have full access to everything. All it takes is a browser exploit and you are cooked.