Andrew Bennetts writes: > No, that just means you shouldn't trust *root*. Which is where a > VM is a very useful tool. You can have the “as root” environment > for your tests without the need to have anything important trust it.
Cameron acknowledges that he missed that. So maybe he was right for the wrong reason; he's still right. But in the current context, it is not an argument for not worrying, because there is no evidence at all that the OP set up his buildbot in a secure sandbox. As I read his followups, he simply "didn't bother" to set up an unprivileged user and run the 'bot as that user. > > 2: Root _can_ corrupt things anywhere in the system (within the > > VM, of course, but the builtbot is a subset of it). A normal > > unprivileged user > > This appears to be a key error in your logic. There's no > fundamental reason why “tests run as root inside a VM” must > necessarily imply “buildbot process is run inside that same VM and > is therefore vulnerable to code in that test run.” Cameron's logic is correct. When security is in question, one must assume that *everything* is vulnerable until proven otherwise. "Is secure" requires a universal quantifier; "is insecure" only an existential one. The principle here is "ran as root" without further explanation is a litmus test for "not bothering about security", even today. It's worth asking for explanation, or at least a comment that "all the buildbot contributors I've talked to have put a lot of effort into security configuration". > It may be more convenient to deploy it that way, You bet, and hundreds of thousands of viruses exploiting IE thank Microsoft for its devotion to convenience. While much can be done to make secure configuration more convenient than it is, nevertheless the state of the art is that convenience is the enemy of security. > but I'm sure it's possible to have a buildslave configured to > e.g. start a pristine VM (from a snapshot with all the necessary > build dependencies installed) and via SSH copy the the source into > it, build it, run it, and report the results. The VM could be > fully isolated from the real network and filesystem etc if you > like. Sure it's possible. In security, the question is never "can it be done?"; it's "was it done?" We have *no* evidence justifying an *assumption* that it was done in the current case, or for other buildbots, for that matter. In fact, as I read the OP's followups, that was *not* the case; the assumption is falsified. Nevertheless, several people who I would have thought would know better are *all* arguing from the assumption that the OP configured his test system with security (rather than convenience) in mind, and are castigating Cameron for *not* making that same assumption. To my mind, every post is increasing justification for his unease. :-( And that's why this thread belongs on this list, rather than on Bruce Schneier's blog. It's very easy these days to set up a basic personal VM, and folk of goodwill will do so to help the project with buildbots to provide platform coverage in testing new code. But this contribution involves certain risks (however low probability, some Very Bad Things *could* happen). Contributors should get help in evaluating the potential threats and corresponding risks, and in proper configuration. Not assurances that nothing will go wrong "because you probably run the 'bot in a VM." _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
