From owner-freebsd-hackers@freebsd.org Sun Oct 22 23:21:11 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 010C3E3979C; Sun, 22 Oct 2017 23:21:11 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id CE34D7D9D7; Sun, 22 Oct 2017 23:21:10 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 9DA2D2D2D; Sun, 22 Oct 2017 23:21:09 +0000 (UTC) Subject: Re: Trust system write-up To: Shawn Webb Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org, freebsd-arch@freebsd.org References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <20171022223133.nkcpkhtl7s7kzgs5@mutt-hbsd> From: Eric McCorkle Message-ID: <96ff2a56-5089-eb4e-cf57-6c6d2cb4667e@metricspace.net> Date: Sun, 22 Oct 2017 19:21:09 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171022223133.nkcpkhtl7s7kzgs5@mutt-hbsd> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 23:21:11 -0000 Accidentally replied to -arch only, re-replying to all lists On 10/22/2017 18:31, Shawn Webb wrote: > I'm curious about the rational behind not requiring expiration of > trusted root key material. > So, I'd say consider most of this written in pencil at this point (minus the signed ELF extension; I think that's a particularly good point in design space). My thinking on root keys is that there really ought to only be one for a given system, but I'm not so convinced of that that I'd bake it into the spec. Certainly, though, you need at least one good root key to stay operational. If you have expiring root keys, you get into all sorts of nasty cases where your last root key expires, forcing the system down, or a system can't be booted because its root keys all expired. And expiring root keys + can't add more root keys means every system effectively has a countdown to running out of root keys. I didn't mention it, but I could see provisions for adding/revoking root keys that hook into some sort of deeper hardware mechanism, say TPMs. I think that's out-of-scope for now, but it's worth thinking about. Perhaps expiring root keys could be added along with a mechanism like this. > Can jails contain a different trust chain than the host? I hadn't really folded jails into this yet, but I'd say that's a definite requirement. It kind of kills the whole virtualization capability of jails if you can't do that. I'd say you'd probably want jails to have the option to inherit their parent's trust DB, as well as establish their own root keys.