or "How do I know my copy of FreeBSD is the same as yours?" I have recently been meditating on the issue of validating X.509 root certificates. An obvious extension to that is validating FreeBSD itself. Under "The Cutting Edge", the handbook lists 3 methods of synchronising your personal copy of FreeBSD with the Project's copy: Anonymous CVS, CTM and CVSup. There are two CTM modes (e-mail and FTP) and you can also download or buy ISOs. Of these six options, only CTM via e-mail has a digital signature, though the ISO checksums can be compared against the signed release announcements. Physical ISOs are a tricky subject - by trusting the content, I am implicitly trusting the vendor (Walnut Creek, Wind River in the past and (eg) FreeBSD Mall now). The FreeBSD project appears to have three official keys: 1) FreeBSD Security Officer (0xCA6CDFB2) 2) Core Team Secretary (0xFF8AE305) 3) CTM e-mail (0xC380B4D8) Of these, only the Security Officer's key has a wide assortment of signatures - providing a reasonably likelihood that an arbitrary person will be able to integrate it into their PGP web-of-trust. The Core Team secretary's key is only signed by four people other than the current secretary - this is somewhat marginal. The CTM key has only a single signature. This is manifestly inadequate. At the very least, the key should be signed by the person who is running the CTM service. The FreeBSD release announcements are currently signed personally by the Release Engineer. IMHO, there should be a FreeBSD Release Engineering key that is used for these announcements. I have also been unable to locate any published information regarding the protection of or access to the private keys for the above. Finally, FreeBSD is dependent on the protection of its DNS entries. Many years ago, I asked about the DNS servers and got a response that I found acceptable. Based on a recent check, I suspect that things have changed - it looks like ns0.freebsd.org is now part of Yahoo. Overall, I believe FreeBSD could be improved by: - Formulating and promulgating a policy for the protection and use of FreeBSD Project DNS, keys and certificates. (The public version of the policy does not go into explicit details but should allow an independent observer to verify its adequacy). - Creating a FreeBSD Release Engineering key which is used to sign official e-mails from the release engineering team - in particular -RELEASE announcements. - Tying all the FreeBSD Project keys together by cross-signing them all. - Arranging for a wider range of signatures on FreeBSD Project keys (the SO key's already meets this). - Investigate obtaining a X.509 certificate for the FreeBSD Project - Signing ISO images with a Project key and/or certificate in addition to providing MD5 checksums. - Investigate providing authenticated protocols for updating FreeBSD. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20051127/4b358597/attachment.bin
Hello Peter, On Sun, Nov 27, 2005 at 09:45:30AM +1100, Peter Jeremy wrote:> Overall, I believe FreeBSD could be improved by: > - Formulating and promulgating a policy for the protection and use of > FreeBSD Project DNS, keys and certificates. (The public version of > the policy does not go into explicit details but should allow an > independent observer to verify its adequacy). > - Creating a FreeBSD Release Engineering key which is used to sign > official e-mails from the release engineering team - in particular > -RELEASE announcements. > - Tying all the FreeBSD Project keys together by cross-signing them all. > - Arranging for a wider range of signatures on FreeBSD Project keys > (the SO key's already meets this). > - Investigate obtaining a X.509 certificate for the FreeBSD ProjectVery much seconded. The security advisories web page, for example, should be available over HTTPS and verifiable by a certificate issued by a recognized CA. Perhaps the releases page should be the same.> - Signing ISO images with a Project key and/or certificate in addition > to providing MD5 checksums. > - Investigate providing authenticated protocols for updating FreeBSD.Also, one should not forget the currently present FTP infrastructure either. While the content is publicly available, their integrity should be verifiable. The same goes for ports distfiles: ideally the should be signed, at least the checksums. The pkg_* tools AFAIK already have sig checking capability for the binary packages, but somehow this should be extended to the "build from source" version as well, particularly since this seems to be the more often used method. -- Regards: Szilveszter ADAM Budapest Hungary
On Sun, 2005-Nov-27 15:27:46 +0000, Ian G wrote:>1. On the wider scope of your post I'd say that you >did not present a need for an x.509 certificate >that I could see.PGP and X.509 have totally different trust models. The PGP Web of Trust relies on each individual knowing and trusting a number of other individuals - a newcomer or someone who is fairly isolated is unlikely to have sufficient links to be able to fully participate. OTOH, the X.509 model requires that the individual trust a central Authority - which might be simpler for a newcomer. (I'm not going to get into a debate on the reliability or reputation of current CAs).>> - Signing ISO images with a Project key and/or certificate in addition >> to providing MD5 checksums. > >No, all you need to do is include the checksums >in a signed announcement. In fact, that's all >that a common digital signature does, so you'd >have to look at why you want more digital sigs...It's trivial to verify an announcement signature when you receive the e-mail. Doing so afterwards can be more problematic. Yesterday, I grabbed the (signed) 6.0-RELEASE announcement from the mailing list archive (http://lists.freebsd.org/pipermail/freebsd-announce/2005-November/001023.html). Whilst the signature was still intact, the content has been changed so the signature no longer verifies. (The changes are presumably mechanical changes as part of its conversion from text to HTML but undoing them would be difficult). -- Peter Jeremy
On Sun, 27 Nov 2005, Peter Jeremy wrote:> or "How do I know my copy of FreeBSD is the same as yours?" > > I have recently been meditating on the issue of validating X.509 root > certificates. An obvious extension to that is validating FreeBSD > itself.This topic has come up countless times over the years, and one of the recurring debates that comes up with it is what it is the "Project" wants to promise, and whether we want to get into the business of managing lots of keying material. Like or not, the weaker the promises you make, the easier they are to keep :-). The concept of even a security officer key has always made me somewhat nervous -- clearly, this is a "valuable" key, but it's also one that has to be made available to anyone who is going to sign a security advisory. We have persistently signed security advisories, errata notes, and release announcements for the past few years, and the release announcements have included release checksums. I think it would be useful to go quite a bit further, but I think we should be careful to do it for pragmatic reasons, and to be very clear on what it is we are doing by signing things, how hard we are willing to try to protect the keying material, and so on. Robert N M Watson
I'm new here, and I've posted only once. I just want to add my "just another user" opinion on this... Signing security advisories that sends the hashes for a file does a nice job. I think the only problem that exists is the package/ports deployment. I belive we can't trust only on hashes for this (tar already does a fine job on integrity...), because it can be easily circunvented. Maybe trusting this it is the real weakest link... One thing that could do a good job is default install gnupg and pre-install some important pgp public keys on ISOs releases, on root's profile... This pre-installed keys can be used by users, ports or pkg_tools, while installing or updating packages/ports. Who will sign is another problem, but I think it will improove things a bit anyway, minimising mitm attacks. My mom used to say "always prefer the pre-installed pub keys...". []'s aristeu
> Can you explain what you mean here. Virtually all distfiles needed to > build a port have MD5 and maybe SHA-256 hashes embedded in the ports > tree. The only way to easily circumvent these is to subvert the ports > tree - which gets back to the issue of trusting the FreeBSD distribution. > I agree that there's currently no integrity checking on packages. > (And, BTW, tar has no integrity checks).Anyone who is between you and freebsd cvsup server can make his own ports tree repository. That being done, he just need to redirect your connection and wait 'til your next cvsup sync is done. About the tar.bz2 archives or what ever you use with tar, yes, if a file is corrupted it doesn't finish decompressing... nice check, huh... :P well, was a joke, sort of.> I don't believe this solves anything. The biggest problem is ensuring > that you can trust your initial keyring or root certificate > collection. Putting "trusted" keys on an ISO only gives you circular > trust - you trust that the ISO image came from the people who made it.There must be a beggining. Or else people will need to go to the headquarters to get the CD or to the CA to get their certificate. Root certficates don't expire?> There's no easy way to verify that it came from the FreeBSD Project. > The FreeBSD project also discourages the inclusion of GPL code in the > base system, making gnupg unattractive as a base system candidate. > Finally, PGP does not have the concept of "important" keys - this is > closer to the X.509 model. The base system already includes tools for > handling X.509 signatures (openssl) and there is already a collection >of X.509 keys embedded in the ports system (security/ca-roots).It's the easiest way I could think of, without inserting another trust point (CA's infraestructure and the people who work on them). I'm not against X.509 signatures, I like them as I like pub key. BUT you need to know that, yet, installing a ca-root certificates port, downloading a public key or resynching your ports tree implies on network transmission of certificates, keys, or hashes. MITM can be done in all that. The part I dont like is that a hash is just a hash. No one owns it. About the GNU part an user from this list, sent me an email telling me there is an BSD license solution comming soon. Thanks markzero for the note. http://netbsd-soc.sourceforge.net/projects/bpg/ Well, anyway, for me, public keys or certificates must be pre-installed on the ISO release and hashes serves only for integrity check, nothing more. []'s aristeu
<snip>> About the GNU part an user from this list, sent me an email telling me there > is an BSD license solution comming soon. Thanks markzero for the note. > > http://netbsd-soc.sourceforge.net/projects/bpg/<snip> It was actually meant to be posted to the list as well, but I forgot to add the CC: line, oops.. M -- pgp: http://www.darklogik.org/pub/pgp/pgp.txt 0160 A46A 9A48 D3B0 C92F B690 17FB 4B72 0207 ED43 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 825 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20051129/6711d5fa/attachment.bin
On Tue, Nov 29, 2005 at 03:44:46PM -0800, Colin Percival wrote:> Kris Kennaway wrote: > > Also, pkg_sign(1) has existed for a long time, but needs the support > > infrastructure to make it usable. > > Last I heard, pkg_sign(1) became non-functional when we changed from > gzipped tarballs to bzip2ed tarballs for packages.Yeah, that could well be true. Kris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20051129/c008909f/attachment.bin