The most direct route to security has the NIC physically removed.
SELinux is unmanageable; just turn it off if it gets in your way
351–360 of 461 posts
Re: SELinux is unmanageable; just turn it off if it gets in your way
#352This is bad advice. SELinux might be hard, but it's neither unmanageable, nor it gets in your way when configured correctly. I've deployed both AppArmor and SELinux in high security environments, and they're nice layers of security to have. Yes, it has a learning curve, but it's worth it.
It is _entirely_ unmanageable for personal usage. The official documentation that the OP found and calls some of the most accessible doesn't teach you how to write a custom policy.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#353Re: SELinux is unmanageable; just turn it off if it gets in your way
#354Earlier 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…
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 deployment, as opposed to deploying holistic systems. We have coders writing apps that feed into our CI/CD system, we have admins who manage kubernetes/Swarm, and we have traditional sysadmins managing VMs. All with differing priorities and focuses.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#355The 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…
/etc/resolv.conf is a funny one. Used to be, you could update it manually. Then NetworkManager (or whatever its successor is) came along and would change it back on you. Oh well, you could still edit it for a quick test. Then I set up a Wireguard tunnel. And it changed /etc/resolv.conf. Oh, but an entry is missing, I'll just add that and test. Nope, read-only. But I'm root! What gives? Turns out the wg-quick script m…
I have, in moments of desperation, `chattr +i /etc/resolv.conf` before. I understand the rationale behind managing that with a more robust service, but in my experience that's much more prone to the black-box effect.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#356This genuinely surprised me - I much prefer SELinux to a number of other access control systems out there (looking at you, Active Directory).
It sort of does the work for you, as long as you 'train' it across a broad enough range of daily tasks. Of course, its not always appropriate to play it that way, but for personal use I've had no issues.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#357Earlier quoted context omitted.
> The problem is not so much that selinux is too complicated (it is as complicated as it needs to be) I disagree. > but that we all run software we don't understand. I fully agree. My disagreement lies in the fact that you've described the problem, but are proposing that some software (SELinux) that fails to solve the problem is somehow good. SELinux might be a perfect tool in an ideal utopia where everyone understan…
>My disagreement lies in the fact that you've described the problem, but are proposing that some software (SELinux) that fails to solve the problem is somehow good. My opinion is that there's a cultural and policy problem and you're simply not going to solve it with technology. I don't think SE Linux is bad, it just isn't the answer here. One (clearly not the only) main reasons people just run a bunch of software the…
> Unlike Civil Engineering, there's no licensing, no sorts of inspections, no oversight, liability is completepy waived in a 300 page agreement people just click through, etc.
This! I have come to the same conclusion. If you want to construct a building you have to comply with multiple standards and industry regulations that serve as limitations and safeguards that follow your project from the initial idea up to (sometimes) the point of destruction of the constructed object.
In our industry even with the standards that we have they are oftentimes treated as guidelines not rules. Of course there are exceptions but those are just a byproduct(or proof) of the rules themselves.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#358The 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…
[deleted]
Re: SELinux is unmanageable; just turn it off if it gets in your way
#359Earlier quoted context omitted.
How does static linking increase workload?
By multiplying the number of potentially-vulnerable copies of a library by the number of ways to detect the presence of said library and by the number of ways to upgrade said libraries when found.
You also forgot to divide by the number of binaries that were compiled with non-vulnerable versions of the library.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#360Earlier quoted context omitted.
> The whole container movement can be seen as putting the apps in a sarcophagus like Chernobyl. […] Who is responsible that it is air tight? Well, uh, nobody, really. The people who designed the container/sarcophagus system. If it's not secure don't sell it as secure: see the difference between Linux containers and FreeBSD jails or Solaris zones. > You can't even blame the applications for that. Let's say you want to…
>> The whole container movement can be seen as putting the apps in a sarcophagus like Chernobyl. […] Who is responsible that it is air tight? Well, uh, nobody, really. > The people who designed the container/sarcophagus system. Original comment misses two nuances with the gripe. 1. Container creators and software creators are not the same people. So they can (and should!) have different goals and priorities. For cont…
> 1. Container creators and software creators are not the same people. So they can (and should!) have different goals and priorities. For containers, security and reliability. For software, make it work.
If the container system designers did their job properly it won't matter what the software does inside of it, as breakouts shouldn't be possible.
It has been a few years since I looked, but last time I checked there hasn't been a vulnerability in FreeBSD's jails code that allowed someone to break out. The closest to it was an issue with devfs that allowed 'tunnelling' out, but not with the actual Jails code itself:
* https://www.freebsd.org/security/advisories/FreeBSD-SA-14:07...
Meanwhile, with Docker (including CVE-2019-5736, which allows for overwriting runc on the host system):
* https://www.cvedetails.com/vulnerability-list/vendor_id-1353...
> 2. There is a nuanced, different interface between software-system and container-system
One keeps things inside and other other often doesn't?