On Wed, 30.04.14 19:56, Marcelo Ricardo Leitner (marcelo.leitner@xxxxxxxxx) 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. > >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. Which attackers can do anyway. If they manage to inject code into your system, then they manage to inject code into your system, that's it. They won. Theres's effectively no difference in whether let's say they can use the SMTP implementation they already find on the system or whether they have to inject their own: the essence is that if they can execute code then they can execute code, whatever code they like. What would be interesting if they could use dead systemd code to escalate privs. But since we don#t ship any suid/fscaps stuff (modulo s-d-v), that's not the case... > >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. Well, that's theatre. It's not security engineering. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
