Re:From Markdown to remote code execution in Atom
by gcb0 on Thursday November 23, 2017 @11:09AM
(#15765894)
when it works for containers, it would have worked just the same for shared lib, but with one less step.
containers: update the lib, rebuild.
sane software: update the lib.
now, to the complicated case which containers claim to solve, when the lib update breaks compatibility.
container: update lib, application dont compile, leave like that because we think we are not vulnerable anyways.
sane sotware: update lib, application break, have to fix application because shared lib will be updated no matter what.
Re:From Markdown to remote code execution in Atom
by AluminiumPoint on Thursday November 23, 2017 @12:48PM
(#15766655)
Sort of. You are missing the ephemeral of containers, which has a net security advantage. Ephemeral containers mean that its harder for an attacker to obtain persistence, and easier to cycle out and swap bad containers than it is to patching servers.
I would argue that container orchestration infrastructure is objectively more secure than plain old servers; I get where you are coming from, but this tech is solving real problems, the cool aid is good
The solution, is to bump the version in the dockerfile, rebuild, and deploy.
This is especially useful when you want to test the latest version before deployment or when you need to deploy to many machines.
Conversely, using a VM and trying to patch it means the updates are not part of the normal development process so you would need to spin up a new VM to test before patching production VMs.
Now sysadmins and developers think differently so this is purely subjective (note I’m a dev), so surely there are merits to the other approach, but I prefer the container approach.