321–330 of 461 posts
Earlier quoted context omitted.
It's pragmatism. If something doesn't work, it doesn't matter how secure it is.
If something isn't secure, it doesn't work. At that point, you would've been better off shipping a wireframe.
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…
Maybe we're just in different circles, or perhaps have different definitions of system design, but that's not been my experience. Usually I see developers being very excited about system design and quite good at understanding system design questions - nothing's more fun than architecting a new system and thinking about stuff like scalability. Where people tend to fail is when they have to implement these systems, and…
This is usually provided by technical books, which are available for a much wider range of systems than you'd think.
Earlier quoted context omitted.
Docker actually comes with a seccomp and an apparmor config that bans many things by default. while it is absolutely not noticeable unless you are trying something like docker in docker. There are so many syscall that shouldn't even be relevant to normal programs.
That's why I explicitly mention "whitelisting". If you just want to ban some obscure syscalls and call it a day, you can do that. It will probably even be helpful to some degree. I personally think our aspirations should be higher than "let's ban ptrace(2)".
It feels good to know that I was not the only one.
Trying to implement SELinux on theses servers would be hugely disruptive, for minimal gain. Once I was able to explain the risk/reward calculation to the Security guys, they understood. Besides, we have so many compensating controls, I have no worries about expanding the attack surface slightly.
Earlier quoted context omitted.
which is why bridges and buildings certified by qualified engineers have never collapsed
Both types of structures have collapsed.
Earlier quoted context omitted.
That's not really great advice either, temporary solutions/workarounds have a tendency of sticking around permanently.
I say this, because it's very hard to write the policy yourself at the beginning. So let the system run for a week and then use the tools to build the policy for you. I wish it's easier to sit down and write it, but it's not atm.
At the bare minimum, you need a base policy that already contains separate type contexts for each of your services, file contexts to apply to the service daemon binaries, and type transitions so that each service gets run in its proper context. If your daemons run in the wrong context, then immortalizing that in policy with e.g. audit2allow only deepens the swamp you're in.
I don't think there's any practical way to build an selinux policy from scratch by just running your system and recording it, even if the tools allow you to do that. You can only start from your OS' reference policy or indeed write the initial base policy by hand.
Earlier 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.
- the distribution to recompile and test all binaries using a vulnerable dependency [x]
- users to download and update all affected binaries
compared to:
- the distribution patching a single package
- users updating that package
Imagine if OpenSSL was statically linked: even the smallest fix would require users to update half of the OS. And that would discourage both maintainer and users from doing regular updates.
[x] And this is assuming that thousands of automated rebuilds are possible. In reality many statically linked languages encourage locking the versions of build dependencies, making it impossible to do just one backport of a patch.