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

Andrew Lutomirski luto at mit.edu
Tue Apr 29 21:09:50 UTC 2014


On Tue, Apr 29, 2014 at 1:57 PM, Marcelo Ricardo Leitner
<marcelo.leitner at gmail.com> wrote:
> Em 29-04-2014 17:04, Andrew Lutomirski escreveu:
>
>> On Tue, Apr 29, 2014 at 12:48 PM, Reindl Harald <h.reindl at thelounge.net>
>> wrote:
>>>
>>>
>>>
>>> Am 29.04.2014 21:36, schrieb Andrew Lutomirski:
>>>>
>>>> On Tue, Apr 29, 2014 at 12:33 PM, Reindl Harald <h.reindl at thelounge.net>
>>>> wrote:
>>>>>
>>>>> simple example:
>>>>>
>>>>> * binary XYZ is vulerable for privilege escalation
>>>>
>>>>
>>>> This makes no sense...
>>>
>>>
>>> for you
>>>
>>>>> * we talk about a *local* exploit until now
>>>>
>>>>
>>>> ...I don't even know what you're trying to say here...
>>>
>>>
>>> than google for
>>>
>>> * "privilege escalation"
>>> * "local exploit"
>>> * "remote exploit"
>>>
>>> that could be a good start:
>>> http://en.wikipedia.org/wiki/Exploit_%28computer_security%29
>>>
>>>>> * a bad configured webserver allows system-commands through a
>>>>> php-script
>>>>>    and i consider that you google for the /e modifier
>>>>
>>>>
>>>> ...and this is already sufficient for a remote exploit.
>>>
>>>
>>> yes, but the difference may be if you only can run unprivileged
>>> code or have a chance to own the machine and get root
>>
>>
>> Can you give an actual concrete example of wtf you're talking about?
>> Because I suspect that you're completely wrong, but maybe you're right
>> and no one on this thread understands what you're trying to say.
>>
>> Feel free to say things like "suppose I have a php app that does XYZ"
>> and feel free to add supposedly vulnerable udev binaries, copies of
>> sh, copies of busybox, copies of python, gcc, etc, as needed for this
>> to make any sense.
>
>
> In simple terms: when you go to sleep at night, do you leave your toolbox
> right in front of your locked front door, ready for anyone to use it on your
> door? I do hope not, and that's the point in here. Or you're just too naive
> to believe that the street wall is just enough to hide it and nothing else
> is needed.

The bad guys have their own tools.

>
> "Ohh but you remove X while program Y can also be used!" Yes, it can! But
> makes it harder, that's the point. Can bash open tcp sockets? Yes. Bash can
> pass through proxies easily? No. But wget can. "Ohh but then someone also
> needs the proxy information" Yes, and that's not the point here. You already
> have 1 obstacle more.

If you want to go down that path, set up selinux to prevent execing
things that oughtn't to be execed.  But trying to prevent exploits
from working by removing every possible helper from the path is a
losing proposition and is just not worth doing.

>
> You have to think out of the box here, we're brainstorming on why a toolbox
> in your front door may or not be a liability. Security is way much more than
> privilege escalation.

> You are not considering that someone may be able to
> trigger an event and simply start a DoS, due to systemd or whatever in
> question not being properly initialized. Exposing this theoretical trigger
> here to you so you "understand it", right now, it out of scope. I hope you
> understand that.

Sorry, wrong.  Systemd *isn't running*, so you can't trigger an event.

--Andy


More information about the devel mailing list