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

[Miloslav Trmač]

2014-05-02 12:47 GMT+02:00 Lennart Poettering <mzerqung at 0pointer.de>:

> On Wed, 30.04.14 19:56, Marcelo Ricardo Leitner (marcelo.leitner at gmail.com)
> wrote:
> > >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)
>
> No, what you are saying technically makes no sense. It really
> doesn't.


 <snip>


> If they manage to inject code into your
> system, then they manage to inject code into your system, that's
> it. They won.


It's not quite *that* simple.  The risk being discussed here is arbitrary
execution *of a command line* (e.g. string injection into system(3)), when
the attacker can run anything available via the namespace but not (yet)
upload their own binaries.

That risk *is* real.  OTOH until someone demonstrates a fully "productized"
application (i.e. suitable for automated setup, configuration management,
security updates) that includes none of: shell, python, coreutils, rpm,
wget, curl (... and many more tools), I don't think it's practical to spend
much effort trying to defend against it; running the suspect code (say, a
PHP application) under an isolated UID with limited privileges is a
reasonable compromise.
    Mirek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140502/fca97d74/attachment.html>