Hello everyone, The following is a write-up of my current design for a public-key trust system: https://www.metricspace.net/files/freebsd_trust.pdf Some of you are certainly familiar with some or all of this; I've discussed parts of it before on -hackers and -security, and I discussed it in greater detail in BoF sessions at vBSDCon. It seems things are heating up in this direction, so I'd like to get this out there and get discussion and feedback. I plan on undertaking work on this in the very near future, especially since the commit-train for GELI EFI is ready to arrive in HEAD. A bit about the format: this is sort of the "meat" of what I hope will be a paper some day, but it's still an initial draft. Moreover, it talks about things I'm planning as if they exist, mainly because I don't want to have to go back and rewrite everything in the future. In reality, most of what I talk about is just a proposal at this point, with a few bits being implemented as a PoC here and there. Please read and consider the designs I've proposed. I welcome any feedback and suggestions. I'll give it a week minimum from today before I resume any work on this stuff. Note: Apologies for the external link; I had originally included this as an attachment, but it was too large.
On Sun, Oct 22, 2017 at 10:14:40PM +0000, Eric McCorkle wrote:> Hello everyone, > > The following is a write-up of my current design for a public-key trust > system: > > https://www.metricspace.net/files/freebsd_trust.pdf > > Some of you are certainly familiar with some or all of this; > I've discussed parts of it before on -hackers and -security, and I > discussed it in greater detail in BoF sessions at vBSDCon. It seems > things are heating up in this direction, so I'd like to get this out > there and get discussion and feedback. > > I plan on undertaking work on this in the very near future, especially > since the commit-train for GELI EFI is ready to arrive in HEAD. > > A bit about the format: this is sort of the "meat" of what I hope will > be a paper some day, but it's still an initial draft. Moreover, it > talks about things I'm planning as if they exist, mainly because I don't > want to have to go back and rewrite everything in the future. In > reality, most of what I talk about is just a proposal at this point, > with a few bits being implemented as a PoC here and there. > > Please read and consider the designs I've proposed. I welcome any > feedback and suggestions. I'll give it a week minimum from today before > I resume any work on this stuff.Hey Eric, Thank you so much for working on this. I do have a few questions. I'm curious about the rational behind not requiring expiration of trusted root key material. Can jails contain a different trust chain than the host? Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20171022/e636026c/attachment.sig>
Hello Eric, On Sun, Oct 22, 2017 at 06:14:40PM -0400, Eric McCorkle wrote:> The following is a write-up of my current design for a public-key trust > system: > > https://www.metricspace.net/files/freebsd_trust.pdfTwo minor things while reading: 1. p2: from a end-user perspective, `trustctl` expects DER encoded certificates and CRL; while `certs` and `rootcerts` outputs PEM encoded certificates? So the formats are not the same, and maybe consistency would be advisable here; 2. p3: 'the preferred configuration' is said to be the most used one, but as described it only includes a single crt+key and does not look suitable for distributing upgrades with freebsd-update(8). Unless I missed something, I guess it's just the way it is described that needs disambiguation: - "local nodes" are basically what is described as "Preferred configuration", and have a single key+crt. So these nodes can only run the code they signed. - "high-security institutions" are kept as it, that is a single crt; So these nodes can only run code signed by the institution. Hybrid systems can be built by having more than one root node: - "preferred configuration" have a local key+crt (as an local node) AND the FreeBSD's project crt. So these nodes can run FreeBSD's code and their own code. - "standard FreeBSD images" as described have the FreeBSD's project crt. When installing, they generates a local key+crt and add them with the FreeBSD crt to the new system's trust store. So these images have the "high-security institutions" scheme, and install systems in the "preferred configuration" scheme. Thanks! Romain -- Romain Tarti?re <romain at FreeBSD.org> http://people.FreeBSD.org/~romain/ pgp: 8234 9A78 E7C0 B807 0B59 80FF BA4D 1D95 5112 336F (ID: 0x5112336F) (plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20171023/6d1a174f/attachment.sig>
On Sun, 2017-10-22 at 18:14 -0400, Eric McCorkle wrote:> Hello everyone, > > The following is a write-up of my current design for a public-key trust > system: > > https://www.metricspace.net/files/freebsd_trust.pdf > > Some of you are certainly familiar with some or all of this; > I've discussed parts of it before on -hackers and -security, and I > discussed it in greater detail in BoF sessions at vBSDCon.??It seems > things are heating up in this direction, so I'd like to get this out > there and get discussion and feedback. > > I plan on undertaking work on this in the very near future, especially > since the commit-train for GELI EFI is ready to arrive in HEAD. > > A bit about the format: this is sort of the "meat" of what I hope will > be a paper some day, but it's still an initial draft.??Moreover, it > talks about things I'm planning as if they exist, mainly because I don't > want to have to go back and rewrite everything in the future.??In > reality, most of what I talk about is just a proposal at this point, > with a few bits being implemented as a PoC here and there. > > Please read and consider the designs I've proposed.??I welcome any > feedback and suggestions.??I'll give it a week minimum from today before > I resume any work on this stuff. > > > Note: Apologies for the external link; I had originally included this as > an attachment, but it was too large. > _______________________________________________Any thoughts on how to validate executables which are not elf binaries, such as shell scripts, python programs, etc? -- Ian