On Tue, 29.04.14 15:36, Marcelo Ricardo Leitner (marcelo.leitner@xxxxxxxxx) wrote: > Em 29-04-2014 12:27, Lennart Poettering escreveu: > >On Tue, 29.04.14 10:37, Daniel J Walsh (dwalsh@xxxxxxxxxx) wrote: > > > >> > >>On 04/29/2014 06:33 AM, Lennart Poettering wrote: > >>>On Mon, 28.04.14 17:01, Daniel J Walsh (dwalsh@xxxxxxxxxx) 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
