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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 29, 2014 at 1:57 PM, Marcelo Ricardo Leitner
<marcelo.leitner@xxxxxxxxx> wrote:
> Em 29-04-2014 17:04, Andrew Lutomirski escreveu:
>
>> On Tue, Apr 29, 2014 at 12:48 PM, Reindl Harald <h.reindl@xxxxxxxxxxxxx>
>> wrote:
>>>
>>>
>>>
>>> Am 29.04.2014 21:36, schrieb Andrew Lutomirski:
>>>>
>>>> On Tue, Apr 29, 2014 at 12:33 PM, Reindl Harald <h.reindl@xxxxxxxxxxxxx>
>>>> 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
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux