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

[Marcelo Ricardo Leitner]

Em 30-04-2014 07:57, Lennart Poettering escreveu:
> 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

Don't ask me, ask when it happens (again)/when the next CVE comes up. 
(and no, I'm not referring to systemd exclusively)

> 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.

That only if you assume that directly executing the wanted binary (being 
a file or not) is the only way to do it.

Please, seriously, I'm not saying (and also was not saying so before 
too, sorry if it wasn't clear) this is the case for systemd. I'm just 
saying that code that seems dead might not be dead on all circumstances, 
for whatever reason. That's my only point here.

> A problem would be tons of suid bianries, or binaries with fscaps. But

Like tricking an application on sending (mass) emails to (unwanted) 
addresses or whatever is okay.

> otherwise dead code lying around is no real additional security
> threat. I am mostly interested in actual security measures, not security
> theatre.

If that's what you think, okay. I do agree with you that suids & all are 
the worse thing. After all, it's like winning the lottery for hackers 
and that's probably where they focus most. But still fear something 
ending up executed via unwanted/unpredicted ways, specially when systems 
are getting more integrated, clever and smarter day after day.

Marcelo