From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from wind.enjellic.com (wind.enjellic.com [76.10.64.91]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0EE144403; Fri, 5 Jan 2024 03:55:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=enjellic.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=wind.enjellic.com Received: from wind.enjellic.com (localhost [127.0.0.1]) by wind.enjellic.com (8.15.2/8.15.2) with ESMTP id 4053sAja017839; Thu, 4 Jan 2024 21:54:10 -0600 Received: (from greg@localhost) by wind.enjellic.com (8.15.2/8.15.2/Submit) id 4053s9ak017838; Thu, 4 Jan 2024 21:54:09 -0600 Date: Thu, 4 Jan 2024 21:54:09 -0600 From: "Dr. Greg" To: Paul Moore Cc: Serge Hallyn , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, corbet@lwn.net Subject: Re: [PATCH 02/13] Add TSEM specific documentation. Message-ID: <20240105035409.GA17707@wind.enjellic.com> Reply-To: "Dr. Greg" References: <20230710102319.19716-1-greg@enjellic.com> <20230710102319.19716-3-greg@enjellic.com> <20230811202254.GA9401@wind.enjellic.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (wind.enjellic.com [127.0.0.1]); Thu, 04 Jan 2024 21:54:10 -0600 (CST) On Thu, Jan 04, 2024 at 10:54:47AM -0500, Paul Moore wrote: > On Fri, Aug 11, 2023 at 4:24???PM Dr. Greg wrote: > > On Tue, Aug 08, 2023 at 01:48:25PM -0500, Serge Hallyn wrote: > > > On Mon, Jul 10, 2023 at 05:23:08AM -0500, Dr. Greg wrote: > > ... > > > > > +of a model. This allows a TMA to attest to the trust/security status > > > > +of a platform or workload by signing this singular value and > > > > +presenting it to a verifying party. > > > > + > > > > +In TSEM nomenclature, this singular value is referred to as the > > > > +'state' of the model. The attestation model is to use trust > > > > +orchestrators to generate the state value of a workload by unit > > > > +testing. This state value can be packaged with a utility or container > > > > +to represent a summary trust characteristic that can be attested by a > > > > +TMA, eliminating the need for a verifying partner to review and verify > > > > +an event log. > > > > + > > > > +TMA's implement this architecture by maintaining a single instance > > > > +vector of the set of security state coefficients that have been > > > > +generated. A state measurement is generated by sorting the vector in > > > > +big-endian hash format and then generating a standard measurement > > > > +digest over this new vector. > > > > > Are you saying the TMA will keep every meaningful measurement for > > > the duration of the workload, so that it can always sort them? > > > > Correct, every unique security state coefficient. > > > > The approach isn't unique and without precedent. Roberto Sassu is > > using a similar strategy in order generate a time/order independent > > PCR value for unlocking TPM sealed keys by parsing RPM and .deb > > distribution manifests. > > > > Paul Moore, in his comments in February to the V1 series, even > > seriously questioned why we would expose the classic linear extension > > measurement from a TMA. > To put my comment from the first revision into the proper context, > and with my understanding that TSEM's security model does not > consider event ordering/timing, I questioned what TSEM would expose > ^^^^ why?? > an ordered list of events to userspace in addition to its unordered, > sorted list. > > Either ordering is important to the security model, in which case you > expose the ordered list, or it isn't, in which case you expose the > list in whatever form is most convenient for the tooling/model; it > makes little sense to me to expose both. As a generic clarification in furtherance of getting everyone on the same page with respect to the focus of our work. TSEM is about providing generic infrastructure for security modeling and anomaly detection that acts at the most precise level of security instrumentation that is available. Secondary to that pursuit, TSEM offers security architects the ability to choose from either a time dependent or a time independent appraisal of a security modeling namespace. The TSEM 'trajectory' file is always time ordered with respect to the first unique occurrence of a security event. In the V3 release, these trajectory entries include a nanosecond timestamp reference, relative to boot, of when the event occurred. The 'measurement' pseudo-file allows a relying party to verify that the trajectory list, as presented, is order/time consistent, if that is what they choose to evaluate. The 'state' pseudo-file allows a relying party to make a decision on whether or not the security status of the system is idempotent, from an event perspective, with a known reference state. It addresses, among other issues, the problem that IMA is currently facing with the fact that handling and examining unconstrained event logs can be problematic from a number of perspectives. Alternately, now in V3, a security model implementator can specify that a security event stream from a modeling namespace be asynchronously exported in its entirety and dealt with in whatever fashion an external evaluator desires. So TSEM doesn't implement or advocate a security model as much as it implements security infrastructure. > paul-moore.com Have a good weekend. As always, Dr. Greg The Quixote Project - Flailing at the Travails of Cybersecurity https://github.com/Quixote-Project