From Markdown to remote code execution in Atom

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.

[ Parent | on HN ]

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

[ Parent | on HN ]

Re:From Markdown to remote code execution in Atom by gcb0 on Friday November 24, 2017 @03:12AM (#15770041)

with shared libraries containers are an option just fine

[ Parent | on HN ]