We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Chris Adams]

Once upon a time, Reindl Harald <h.reindl at thelounge.net> said:
> google as example for CVE-2014-0038 and as i already explained
> you: a attacker has no shell, you have two ways to force a existing
> local exploit by a web-application:
> 
> A: try to get a complete script on the machine and execute it
> B: find a very likely present binary and bring it to do the
>    rest of the attack for you with arbitary input

If I can run arbitrary code as your web user, I can do whatever your web
user can do.  If your kernel has a security hole, I can exploit that.
If I can run PHP code, there's a million things that I can do.  If I can
run shell code, I can do just about as much.  How does the existence of
a non-privileged systemd binary affect that?

I understand "defense in depth", I just don't believe the existence of a
non-privileged systemd binary has a non-negligible effect on system (or
container in this case) security.  If I can run an arbitrary binary on
your system, you are already owned.  I can run /bin/sh (for example,
just because it is nearly universal) and fetch other arbitrary binaries.

Do some binaries being available possibly make an attack easier?  Maybe,
but that work is generally figured out once by "smart" people, and then
exploited a million times by script kiddies.  Something being "harder"
doesn't add anything mcuh to security, because it _can_ be figured out,
will be, and then it'll be copy&pasted repeatedly (and you haven't
gained a significant advantage from "it is harder").

-- 
Chris Adams <linux at cmadams.net>