Once upon a time, Reindl Harald <h.reindl@xxxxxxxxxxxxx> said: > google as example for CVE-2014-0038 and as i already explained > you: a attacker has no shell, you have two ways to force a existing > local exploit by a web-application: > > A: try to get a complete script on the machine and execute it > B: find a very likely present binary and bring it to do the > rest of the attack for you with arbitary input If I can run arbitrary code as your web user, I can do whatever your web user can do. If your kernel has a security hole, I can exploit that. If I can run PHP code, there's a million things that I can do. If I can run shell code, I can do just about as much. How does the existence of a non-privileged systemd binary affect that? I understand "defense in depth", I just don't believe the existence of a non-privileged systemd binary has a non-negligible effect on system (or container in this case) security. If I can run an arbitrary binary on your system, you are already owned. I can run /bin/sh (for example, just because it is nearly universal) and fetch other arbitrary binaries. Do some binaries being available possibly make an attack easier? Maybe, but that work is generally figured out once by "smart" people, and then exploited a million times by script kiddies. Something being "harder" doesn't add anything mcuh to security, because it _can_ be figured out, will be, and then it'll be copy&pasted repeatedly (and you haven't gained a significant advantage from "it is harder"). -- Chris Adams <linux@xxxxxxxxxxx> -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
