Sorry for taking so long to respond to this. On Tue, 2017-10-10 at 20:36 +0200, Ansgar Burchardt wrote: > Ben Hutchings writes: > > On Mon, 2017-10-09 at 17:38 +0100, Steve McIntyre wrote: > > > On Mon, Oct 09, 2017 at 02:01:15PM +0100, Ben Hutchings wrote: > > > > [...] > > > > It also appears to mean that buildds can get anything signed on demand > > > > with no human intervention at all, without all the checks that dak does > > > > on uploads. This seems to be to substantially raise the risk of > > > > signing evil code and needing to revoke those signatures (or the > > > > signing key). > > > > > > We spoke about this too. Source packages uploaded and eventually built > > > on the buildds already go through dak and wanna-build, for one. We > > > have to trust that mechanism already. > > > > It's also audited - every upload is publicly logged, which makes it > > hard for an attacker to hide an evil upload. > > Does anyone ever look at the upload history of buildds and audits them? I don't know. But as I understand it, nation-state attackers generally don't like to leave traces, so public logs can be a valuable deterrent. > > A signing service would have to implement a separate audit mechanism. > > And code signing can't be time limited so if we sign an evil upload > > we'll need to revoke it somehow. > > Hmm, last I asked revocations weren't a concern for kernels with a valid > signature and known vulnerabilities that can be used to bypass the > secure boot foo either. I suppose there's not that much difference between those in terms of threat. But I think that if we directly signed malicious code we would be practically (or even legally) obliged to revoke it asap. > > > What human intervention are you wanting here? > > > > A human decides when processing the BYHAND queue whether this binary > > upload looks reasonable. > > That's really not going to happen. I don't want to manually process > packages. I very strongly doubt the other ftp-masters want to either. > > What should the human check anyway? That someone signed the source > upload? That someone (or something for buildds) signed the binary > upload? That is already done automatically; looking at the source code > is unreasonable (and might not correspond to binaries anyway when you > consider evil uploads). They can check whether the binary upload actually came from a buildd, and whether there was a recent source upload or binNMU request. It's not that strong a check, but seems somewhat better than an on-demand signing service. > > Also, dak checks that every binary upload corresponds to a source > > upload, so an evil upload will have to be either a source upload or a > > replacement of a binary upload. It seems like the proposed signing > > service would allow an attacker that compromises a buildd to get code > > signed at any time, independently of a source upload. > > No, it doesn't. dak only checks that a package claims to come from a > source package present in the archive; otherwise binNMUs would not work. Fair point. > For an upload containing only byhand files not even that is checked. I don't think anyone proposed to make uplaods that only contain byhand files. > Also we have the problem with "evil uploads" everywhere... It doesn't > really matter if the kernel (with secure boot) is fine if userland is > not. I know, but we have to start somewhere. (And Matthew Garrett is working on the userland side for Google's internal Debian derivative.) > (And I'm not even going to start how everyone with upload permissions > can exploit buildds to upload arbitrary packages or insert bad code in > other, unrelated packages built on the same buildd. Including the > secure boot signed packages.) This is all true, but it sounds like you are succumbing to security nihilism: "we can't make this perfectly secure, so we shouldn't make it more secure". > > > > On the other side... there is an FTP team objection with no documented > > > > explanation. > > - byhand files for security-master break the security-master -> > ftp-master sync > - The autobyhand scripts don't work for uploads that go to NEW. Damn. > - byhand files are not that nice; I would rather not add more of them I don't think any solution is going to be "nice". > - byhand files aren't publish in the public archive, so harder to see > what was actually signed. Nothing enforces the binaries in the *.deb > and the *.tar.gz are related after all. Or that a *.deb is present. That's true, but seems fixable. > - Not clear how to publish signed binaries for the manual step in > preparing uploads for the security archive. That seems like a relatively easy problem. Ben. > I admit I don't like requiring access to a signing service on buildds > either. It also makes it harder to trust the build process less in the > future (for example by moving it to a VM so it is restricted to do evil > stuff only the the current build, not having access to private keys and > removing access to network services). -- Ben Hutchings Beware of programmers who carry screwdrivers. - Leonard Brandwein
Attachment:
signature.asc
Description: This is a digitally signed message part