selinux relies on the basis of deny all, allow only ideas. On paper that’s fine, but when you are troubleshooting issues, installing software or developing applications, it can hinder productivity by preventing the user from doing things.
Selinux CAN work, but it absolutely requires a lot of time investment and maintenance to keep it working well with audit.d and general logging.
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.
Because apparently people are stuck in the mindset of about 10 years ago when people used to get tripped up over it. SELinux is rarely ever a problem for anything these days. This post is dumb.
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.
Yeah, AppArmor is a lot more straightforward. I could buy an argument that technically the SELinux approach is more flexible, but it’s hard to imagine someone needing that much flexibility in the general use case.
I can understand why something like Android could get more mileage out of SELinux’ model, but most scenarios are very capably modeled by AppArmor approach and much easier and less fragile functionality wise.
You have two applications installed which bring their own labels and rules, lets say app_a_t and app_b_t.
Now you want to give AppA read access to only one specific directory of AppB data (which is labeled app_b_t).
How to do that? Writing a rule allowing acces between the labels would give AppA access to all of AppB data. Creating a new label for this specific dir would break AppB as it relies on the rules for app_b_t.
My biggest issue with SELinux is that files and applications can not have multiple types at once (like with a role based model).
Why is it bad?
Because developers are bad at using it. How many times have you seen a installation instructions telling you to turn it off
More than once, now that I think about it
selinux relies on the basis of deny all, allow only ideas. On paper that’s fine, but when you are troubleshooting issues, installing software or developing applications, it can hinder productivity by preventing the user from doing things.
Selinux CAN work, but it absolutely requires a lot of time investment and maintenance to keep it working well with audit.d and general logging.
I might get down voted for this, but I’ve honestly found LLMs pretty useful tools for debugging SELinux.
Ironically, SELinux might be a pretty good tool to keep LLMs from accidentally getting the answers to their benchmark
git gud
git: ‘gud’ is not a git command. See ‘git --help’.
The most similar command is
I love this. First time seeing it.
Only in enforced.
Just set setenforce 0 for this
for this see policy log and create selinux policy with generator if developer was lazy
Highter productivicy before someone still all your code (like binance)
So the correct way to use SELinux is to checks notes disable it
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.
Because apparently people are stuck in the mindset of about 10 years ago when people used to get tripped up over it. SELinux is rarely ever a problem for anything these days. This post is dumb.
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
chconbecause 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.
Over the last year I have done this entire. Went from app armor to SEL and now I’m back on app armor.
You couldn’t pay me enough to try SEL again.
Yeah, AppArmor is a lot more straightforward. I could buy an argument that technically the SELinux approach is more flexible, but it’s hard to imagine someone needing that much flexibility in the general use case.
I can understand why something like Android could get more mileage out of SELinux’ model, but most scenarios are very capably modeled by AppArmor approach and much easier and less fragile functionality wise.
In some usecases SELinux is less flexible:
You have two applications installed which bring their own labels and rules, lets say
app_a_tandapp_b_t. Now you want to give AppA read access to only one specific directory of AppB data (which is labeledapp_b_t).How to do that? Writing a rule allowing acces between the labels would give AppA access to all of AppB data. Creating a new label for this specific dir would break AppB as it relies on the rules for
app_b_t.My biggest issue with SELinux is that files and applications can not have multiple types at once (like with a role based model).
It assumes the user is an idiot. And it assumes the user should not own their own device.
That is the core tenant of how it works.
Aka deny all base line.
tenet