Em 30-04-2014 07:57, Lennart Poettering escreveu:
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
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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
