> They’re looking for solutions — preferably quick ones — and not a week’s worth of study.
welp, there's your problem. sophisticated tools require study and care, not a quick hack.
SELinux is unmanageable; just turn it off if it gets in your way
401–410 of 461 posts
Re: SELinux is unmanageable; just turn it off if it gets in your way
#402As an experienced RHEL admin, a few years ago I probably would have said this is very bad advice in any professional context, and you should spend the time to learn it because it will save you one day. Now, I think my advice would be: Put everything in a container, and learn how to run Docker or Podman (or k8s) in a secure way (ie no root containers, be very careful with volume mounts, etc). Yes, they aren’t as matur…
I'd generally agree with this, but for production use (where it'll be CRI-O or ContainerD in all likelihood) it's worth noting that using containers does increase your attack surface. We've had container breakout CVEs in the Kernel+ContainerD+CRI-O this year, and the ContainerD/CRI-O ones were not complex at all, so you do need to stay on top of patching as well as the other good practices mentioned.
A lot the container breakout CVEs do not affect a system that uses SELinux properly.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#403Eh, I generally disagree - but not completely. Set SELinux to permissive for your personal systems at your own relative risk. Never disable it, you'll end up in a situation where nothing is labeled and relevant policy adjustments probably don't exist. Making re-enabling it later a nightmare. I'd argue it's particularly advantageous for desktops where untrusted software is a more common occurrence... and other control…
It's been years since I was responsible for administering Linux Servers, but half the issues I ran into were generally fixed with `restorecon`. I used to be that "never disable SELinux" person, but I've since become a bit more pragmatic. But I still think you should at least spend a bit of time trying to get it to work before defaulting to `setenforce 0`. I'm a Detection and Response Engineer now, Analyst for several…
Yea, pretty much.
Restoring the defined contexts is the appropriate method -- the policy modifications to make $service work should be well defined at the time of integration, never a surprise.
If something is suddenly breaking because it needs to break a new policy, that's a problem with the processes being followed or the software; not SELinux.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#404As an experienced RHEL admin, a few years ago I probably would have said this is very bad advice in any professional context, and you should spend the time to learn it because it will save you one day. Now, I think my advice would be: Put everything in a container, and learn how to run Docker or Podman (or k8s) in a secure way (ie no root containers, be very careful with volume mounts, etc). Yes, they aren’t as matur…
By using containers you can multiply your security problems!
That is, it does nothing to address security problems latent to each container binary.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#405No post body was provided.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#406SELinux, and all of the other bolt on security model extensions, all have a parallel system problem. Fundamentally it's about adding a security definition layer that just doesn't exist in the traditional UNIX privileges model; and it isn't even the typical extension of ACLs on objects. Instead it's a whole new set of tools or patch extensions to existing tools (which may as well therefore also be custom tools) that is completely opaque and therefore impossible for anything to interact with or provide good error messages for when it does inhibit interactions.
What I really dislike about SELinux and similar tools is the pivot in management. Inevitably since they're bolt-ons they also add a second policy area, no longer on the file or device but instead in some other database of inscrutable configuration files. A second and totally alien location to check when anything isn't working.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#407I agree that SELinux is largely unusable in the real-world (especially for custom apps). I've had better experience with path based MACs like tomoyo and apparmor. Firejail is also great for end users who want to safely do online banking and surf the web at random on the same machine. IMPO, this sort of isolation is the future of endpoint security. Linux has seccomp (to filter syscalls), landlock (to limit filesystem…
Out of all the tools you mentioned, pledge and unveil are the most pleasant to use from a developer and operator's perspective. I'm hoping something something similar will arrive in Linux without it becoming xkcd 927.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#408Earlier quoted context omitted.
I've tried to explain to our Devops guys that they need to automate their patching so that a new container is fully patched before deployment. They had no idea what I was talking about. I said, "you have containers that run for months, right? And they aren't modified at all after deployment, right? So how do you address new vulnerabilities? How often are you patching your base image?" Just clueless looks.
If that matters why hasn't the internet exploded yet? Hardly anyone is doing that thing and it seems to not matter. People who panic only when they see $STUPIDLY_NAMED_ISSUE seem fine.
Unless there's a vulnerability in something internet facing, you can go a very long time without updating anything. So, yes, it doesn't matter... except when it does. I've logged into production systems with multi year uptimes, with updates that haven't been applied in just as long.
Many orgs have a if it's not broke, don't fix it policy. Applying needless updates are just as likely to screw something up.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#409SELinux, and all of the other bolt on security model extensions, all have a parallel system problem. Fundamentally it's about adding a security definition layer that just doesn't exist in the traditional UNIX privileges model; and it isn't even the typical extension of ACLs on objects. Instead it's a whole new set of tools or patch extensions to existing tools (which may as well therefore also be custom tools) that i…
Since security properties are a global aspect of a system there is something to say for having them sit separate from the rest of the system. On the other hand that means every change (potentially) has to be made twice.
It's good if you want to have a committee check every change but it slows changes down accordingly.
Contrast that to
https://en.wikipedia.org/wiki/Capability-based_security
where the reference to an object and the access to the object are tied together. On paper it's a great model but it hasn't seen a lot of real life use.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#410The problem is not so much that selinux is too complicated (it is as complicated as it needs to be), but that we all run software we don't understand. The whole IT ecosystem has become a hail mary. Even admins usually have no idea what a certain program actually wants to do. If the admin knows how to install the app so that it actually runs, you call them a good admin. From a security point of view, an application is…
Honestly, the bigger issue is that most SWEs just aren’t very good. It’s extremely telling that when you spend time in tech forums most people dread system design questions as the harder side of interviewing for senior level SWE roles… System design, though, is the actual point of SW ENGINEERING. That’s the part that is responsible for creating a foundation of quality to build on. The other side is that sysadmins hav…
Speaking personally, the reason I dread system design questions is because it's asking me to give an off-the-cuff answer to something I would prefer to take weeks to consider and research.