Earlier quoted context omitted.
> it is your responsibility to know how the components you choose work and how much you can rely on them Unfortunately that is not always your choice and arguing against it most commonly costs you more than you like. My experience is quite often timelines get underestimated massively with software so you end up doing what you can with the resources given. If you pull this into the bridge metafore the bridge still sta…
Yep, this is accurate. People making decisions often value “works”/“ships” more than “secure” and the time allocations reflect it. I wish it wasn’t the case, but it is.
SELinux is unmanageable; just turn it off if it gets in your way
281–290 of 461 posts
Re: SELinux is unmanageable; just turn it off if it gets in your way
#282The 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…
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 have largely become DevOps or SRE roles, which means most folks left as a sysadmin are those that couldn’t hack it in the other roles. In the end, as we grow the number of people in tech, the number of software and systems, and the complexity we experience a regression to the mean across the board.
It’s always been a pet peeve of mine that I can count on my hand the number of SWEs in my ~20yr career that had similar understanding of the system they worked with as their SRE counterparts… but this should be table stakes.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#283Earlier quoted context omitted.
> there is no overview documentation, Documentation on Linux has always been shit.
Huh? Compared to what exactly? Man-pages compared to MS provided info are fairly exhaustive.. Now if we are talking of a documentation of a random project on github..
The man depend on the utility. Except for the GNU stuff, where the man pages often tell you to look at the info pages.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#284Re: SELinux is unmanageable; just turn it off if it gets in your way
#285Earlier quoted context omitted.
The problem is that we have built all our software on Unix. The Unix security model is based on an attack model where users have to be protected from each other on a terminal server. Code is implicitly trusted and exploits were an unknown unknown. That security model is almost completely useless now. Terminal servers are an extreme edge case. Services implement their own security model between users. Special “Users”…
Is Windows much better with its VMS legacy kernel? It has a complex permission model with ACLs and everything but that trades inadequate permissions for something like the SELinux problem. There are too many knobs. (For this discussion leave aside the backward compatibility baggage which is another issue.) The only approach that I see as viable without rebuilding the entire compute universe is VMs, either the web bro…
Congratulations, you have just introduced an L1TF attack surface, and the bad guys are now freely reading all physical memory.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#286Earlier quoted context omitted.
Yep, this is accurate. People making decisions often value “works”/“ships” more than “secure” and the time allocations reflect it. I wish it wasn’t the case, but it is.
It's pragmatism. If something doesn't work, it doesn't matter how secure it is.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#287Re: SELinux is unmanageable; just turn it off if it gets in your way
#288Earlier quoted context omitted.
> it is your responsibility to know how the components you choose work and how much you can rely on them Unfortunately that is not always your choice and arguing against it most commonly costs you more than you like. My experience is quite often timelines get underestimated massively with software so you end up doing what you can with the resources given. If you pull this into the bridge metafore the bridge still sta…
Yep, this is accurate. People making decisions often value “works”/“ships” more than “secure” and the time allocations reflect it. I wish it wasn’t the case, but it is.
If a datacenter continues to purchase a model of generator after five high-profile failures of that model, they can argue all they want that it is the only model on the market that meets their needs. But clearly uptime is not their biggest consideration.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#289The 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…
Yes. It's absurd that anyone that can talk about this stuff at a basic level is seen as some sort of ultra-skilled professional. See also: the relatively small amount of chatter about this stuff in the blogosphere, where there's a million tutorials that amount to "here's how you run create-react-app" and about 3 that talk about even moderate system design topics.