Michael Buesch wrote: >On Friday 14 November 2008 21:09:43 John Kasunich wrote: > > >>Sebastian Kuzminsky wrote: >> >> >>> # let the farm user run "sudo make setuid" without a password by >>>adding this line to /etc/sudoers: >>> farmer ALL = ALL, NOPASSWD: /usr/bin/make setuid >>> >>> >>> >>This part raises a red flag for me, as I mentioned on IRC last night. >> >>If you set this passwordless sudo, then it is theoretically possible for >>somebody to check a trojan makefile into our CVS, and a few minutes >>later it would run on your box as root. If your buildbot system is a >>dedicated virtual machine used for nothing else, the risk is probably >>tolerable. I would NOT make this change to /etc/sudoers if "farmer" is >>a user on a non-virtual machine that you use for other things. >> >>The odds of such a thing happening are slim - Joe Hacker can't commit a >>trojan, only someone with commit access to the server could do it. And, >>the CVS logs would tell us exactly who it was, so we could give them the >>beating they so richly deserve. But the risk needs to be acknowledged. >> >> >They guy has root access to the machine, so he can manipulate the CVS database >and obfuscate the commit. > > The CVS database isn't on any machine that a malicious committer has access to. The attacker would only have root access on the slave machine, which uses an anonymous checkout from the CVS server.
>Heck, he can even start a telnet/ssh session or whatever. He's root! > > To what? Again, the hypothetical attacker has no login for the CVS server. >I don't think there is a solution for this, however. >If you want to run a component of the repository (be it the makefile or >the setuid programs itself) as root, you need to trust your committer. > > These scripts don't run on the CVS server, they run on machines that volunteers (like you :) ) would set up. The potential issue is that you, as a volunteer, could allow root access to your machine. That's why John K suggested that a safe thing to do is to use a VM only. >You could run it in qemu or whatever, but what is it good for then, if you >don't have the real hardware access to test RT... >(Two seperate machines could be a solution, well...) > Yeah, RT testing opens up interesting issues. What if some RT module crashes the machine? Also the testing can't be comprehensive, since the buildbot machines are unlikely to have any hardware other than a parallel port (if that), so we can't actually test all of the RT drivers anyway. - Steve ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
