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

[Lennart Poettering]

On Tue, 29.04.14 15:36, Marcelo Ricardo Leitner (marcelo.leitner at gmail.com) wrote:

> Em 29-04-2014 12:27, Lennart Poettering escreveu:
> >On Tue, 29.04.14 10:37, Daniel J Walsh (dwalsh at redhat.com) wrote:
> >
> >>
> >>On 04/29/2014 06:33 AM, Lennart Poettering wrote:
> >>>On Mon, 28.04.14 17:01, Daniel J Walsh (dwalsh at redhat.com) wrote:
> >>>
> >>>>The problem  is lots of services require systemd because they ship a
> >>>>unit file and want systemctl reload to happen.  Systemd then triggers a
> >>>>require for udev and kmod, which docker containers do not need.
> >>>If you discount the docs/man pages of the RPMs, how much does kmod,
> >>>udev, systemd actually contribtue in bytes to your docker images?
> >>>
> >>>Lennart
> >>>
> >>Shrinking the the docker image is more then just size.  We want to
> >>eliminate packages that are not used (Within reason) to eliminate
> >>problems like CVE's.  If udev/systemd/kmod had a CVE we would need to
> >>update all Container images.
> >
> >Well, if you are this principled maybe. But do note that we dont really
> >ship suid binaries (except one binary with fscaps which is
> >systemd-detect-virt), and hence by leaving systemd in the image without
> >running it should result in no increased attack surface that wasn't
> >there anyway... Dead code in the image, that cannot be use to acquire
> >new caps isn't much of a security threat...
> 
> You're considering only the escalation way to do it, but there are
> other ways to exploit code laying around, like when some web pages
> don't sanitize the URL enough and end up allowing executing
> something in the system, much like sql injection. In those cases,
> one could craft URLs to run wget or any other tool that may help the
> intruder get even more inside.
> 
> It's a pile of faults, yes, but the result isn't good and one good
> preventive step is keeping the dead/not needed stuff away.

This makes no sense. I mean, why would anyone bother with playing with
systemd's binaries which (with the exceptio of s-d-v, see above) do not
increase your set of capabilities when executed, if you have /bin/sh
anyway which allows you to do whatever you want? If an attacker managed
to inject code in your system, then systemd's tools won't allow him to
do anything he couldn't do anyway, either directly with injected code or
by invoking /bin/sh and then continuing from there. Hence the attack
surface is not increased.

A problem would be tons of suid bianries, or binaries with fscaps. But
otherwise dead code lying around is no real additional security
threat. I am mostly interested in actual security measures, not security
theatre.

Lennart

-- 
Lennart Poettering, Red Hat