Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SELinux is unmanageable; just turn it off if it gets in your way

ctrl.blog

Post reply on HN
Print view View original

381–390 of 461 posts

Re: SELinux is unmanageable; just turn it off if it gets in your way

#381

Post by ThenAsNow »

auto wrote: post #247
viccuad wrote: post #219

Earlier quoted context omitted.

The engineer building the bridge is liable. Hence, you get engineers with qualifications (instead of a random person with X years in Y), and those qualifications certify they know what they are doing.

Which in my opinion brings up the certification argument, but I, as I’m sure others, have found that most certifications mean nothing in regards to whether someone can actually do the job. Is the key component missing in hiring in our industry a vastly more rigorous/extensive/difficult testing and certification protocol?

I'm an engineer in physical disciplines, and I don't think it's a certification issue. It's more that "engineering" in the software world is conflated with craftsmanship. The word "engineering" as used in relation to software is basically interchangeable with "technical work". Let me hasten to add, this is not intended to be pejorative or haughty, rather an observation.

Whether it's bridges, aircraft, or other complex engineered systems outside of software, there is a fundamental commitment to correctness, as assessed against physical principles such as conservation laws and both high-level and low-level verification criteria. Some software orgs (I think mostly in safety-critical systems) apply this kind of rigor, but most software development does not. Just look at the pushback on this site for development systems that increase rigor at the expense of "development velocity", such as memory-safe languages, powerful type systems, formal methods, etc. No civil engineer is going to be OK "shipping" their product without stress analyses, material property knockdowns, and the like.

My suspicion is that the root of this lies in an inability to systematically reason about software the same way we can about physical systems today. The tools and principles for correct-by-construction software are more primitive and harder to use than their equivalents in the physical realm. Also, lack of rigor in software still gets you a lot of powerful software and society seems remarkably tolerant of shitty software outcomes.

All software doesn't need to be engineered, the same way no one engineers a hand-crafted piece of furniture. But our software infrastructure ought to be, and it surely is not today. It will be awesome when software engineering starts living up to its billing, as I hope it one day does.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#382

Post by remyabel »

Copy/pasting the comment I made on the blog.

I have to say that I strongly disagree with the arguments made and the advice. Disabling SELinux is a terrible idea, it will increase the attack surface of your system by magnitudes. I'll be addressing arguments made (paraphrased, not direct quotes).

A) "SELinux documentation is too complicated and geared towards policy makers, not end users"

This is because the documentation's target demographic are system administrators using the tools to write policies. This is like complaining that a carpenter handbook aimed at professionals is too complicated for end users. You want to be looking at either the documentation for the software (Docker for example tells you how to get around permission errors with mount, or setting the appropriate bool for httpd servers) or reading the error message that tells you exactly what to do (run audit2why, file a bug report so the distro maintainers can take a look at it).

B) "You should disable SELinux"

Would you disable your home security system because it's too complicated to figure out? If there is a genuine bug in the policy, then it should be reported, not disable the entire thing.

C) "Start from a clean slate and write your own policies"

The policies are written by those who are intimately familiar with SELinux and how it operates within the context of the distro. Again as said earlier, if there's an issue, report it upstream. Trying to write your own policies, especially if you're unfamiliar with SELinux, will result in an insecure application/system. Most errors are easily solved by google or running the appropriate command.

D) "It's too complicated for end users; use Docker instead"

I see this argument a lot, but it makes no sense within the context of IT. The end user and system admin are two different groups of people. Why does it matter if it's too complicated for end users when the audience are other IT professionals? Docker also is NOT a replacement for SELinux. Docker is secured BY seccomp profiles, by itself it is actually significantly more insecure than people think. This shows a fundamental misunderstanding of the threat model of containers and what benefits SELinux provides.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#383

Post by monkpit »

greedo wrote: post #354
monkpit wrote: post #343

Earlier quoted context omitted.

How would you accomplish this exactly? Your use case may vary, but in my mind dependencies shouldn’t just be upgraded by some automated system without some sort of feedback mechanism (like tests). If you’re going to run tests against the new dependencies, then why not just shift that whole activity to the development process itself (not the deployment system)? When dependencies are sufficiently different from the exi…

I'm actually agnostic as to how it's achieved. I just think that the idea of running a container for three months without patching the underlying OS is nuts. Generally our guys only redeploy a container when there's been an update, so that OS is pretty stale compared to what I'm running on traditional VMs. It really was more of a reflection on how DevOps can become too focused on application development and deploymen…

Ah, the OS itself. I thought you meant the application dependencies.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#384

Post by Spivak »

greedo wrote: post #354
monkpit wrote: post #343

Earlier quoted context omitted.

How would you accomplish this exactly? Your use case may vary, but in my mind dependencies shouldn’t just be upgraded by some automated system without some sort of feedback mechanism (like tests). If you’re going to run tests against the new dependencies, then why not just shift that whole activity to the development process itself (not the deployment system)? When dependencies are sufficiently different from the exi…

I'm actually agnostic as to how it's achieved. I just think that the idea of running a container for three months without patching the underlying OS is nuts. Generally our guys only redeploy a container when there's been an update, so that OS is pretty stale compared to what I'm running on traditional VMs. It really was more of a reflection on how DevOps can become too focused on application development and deploymen…

I kinda stopped worrying too much about it because the "OS" (really userspace) that lives in a container isn't in a position to be exploited like the underlying VM OS is. Nothing in the container is privileged and there are no security boundaries that exist within a container. You should care exactly as much about container image updates as you do gem/npm/pip updates and I guarantee you have months old deps pinned in a lockfile somewhere.

What people hear is "Oh my god you're still running Ubuntu 14.04?!?" but what is actually happening is all the defenses and security boundaries are being enforced by a fully patched RHEL 7 instance with SELinux, the completely unprivileged application code just happens to have an old version of libz bundled with it. So for sure the application is in a position to be compromised depending on how old the libs and the vulns that might exist but that's the developer's concern exactly like their NPM deps.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#385

Post by dylan-m »

nottorp wrote: post #185

Basically linux is moving from a hobbyist operating system that a single person can reasonably manage in their spare time to an enterprise ish complex monstruosity that requires training and a time investment. Probably because the main Linux sponsors have found that it's the only way to make money with it. SELinux... systemd... who knows what's coming next. Let's not forget ipv6, although that's not a linux specific…

> Basically linux is moving from a hobbyist operating system that a single person can reasonably manage in their spare time to an enterprise ish complex monstruosity that requires training and a time investment

This is less a Linux problem, and more an Internet problem. The reason we have more security vulnerabilities now is not because software suddenly sucks and everyone is incompetent (rather, that is a universal constant): it is because software is valuable, and the internet is huge. That is why we need ipv6, but more importantly that is why we need tools that provide security in depth, which is a great deal of the complexity in Linux today. (For example, there are heaps of vulnerabilities that sound terrible, but we know their effects will be mitigated by a container, or by SELinux). Yes, as a hobbyist, one could probably grab a copy of Debian 2.2 Potato and host a website from it. Running a modern stack sounds like an investment? Keeping that afloat will need a dedicated team.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#386

Post by tristor »

throwaway889900 wrote: post #311
tristor wrote: post #282

Earlier quoted context omitted.

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…

>System design, though, is the actual point of SW ENGINEERING. I thought system design was the point of system engineering?

Software is a system.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#387

Post by _joel »

monkpit wrote: post #343
greedo wrote: post #332

Earlier 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.

How would you accomplish this exactly? Your use case may vary, but in my mind dependencies shouldn’t just be upgraded by some automated system without some sort of feedback mechanism (like tests). If you’re going to run tests against the new dependencies, then why not just shift that whole activity to the development process itself (not the deployment system)? When dependencies are sufficiently different from the exi…

If you're using an upstream image from a distro, pull that down, update it, push it back to a registry, then use that as your base image. Do that every day in a CI/CD (or just cron) system, such that you've got logs, auditing and fires off alerts if something breaks.

Add update steps to the builds of your final image containers too at the start, to catch any delta that may have happened during last base image patch.

There are also container scanning tools but they can produce some false positives sometimes but useful nonetheless.

You still run tests as normal against the new images before promoting, just like normal.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#388

Post by [deleted] »

monkpit wrote: post #343
greedo wrote: post #332

Earlier 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.

How would you accomplish this exactly? Your use case may vary, but in my mind dependencies shouldn’t just be upgraded by some automated system without some sort of feedback mechanism (like tests). If you’re going to run tests against the new dependencies, then why not just shift that whole activity to the development process itself (not the deployment system)? When dependencies are sufficiently different from the exi…

[deleted]

Re: SELinux is unmanageable; just turn it off if it gets in your way

#389

Post by xyzzy123 »

greedo wrote: post #332
Sebb767 wrote: post #298

Earlier quoted context omitted.

I fully agree with your last point. In my experience, the all-versions-packaged approach of containers actually leads to a worse patch state than a simple Ubuntu or Debian installation with unattended-upgrades.

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.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#390

Post by joshbaptiste »

rubyist5eva wrote: post #257

As someone who is relatively new to the Redhat ecosystem, what exactly is the purpose of SELinux? If you only run trusted applications why do you need it?

Trusted applications can be full of vulnerabilities that allow them to become malicious. SELinux and such can limit the capabilities of such trusted applications to do only what they were designed to do and not execute reverse shells or run Crypto mining software etc..
Post reply on HN