Re: [RFC PATCH 0/3] Add additional MOK vars

From: "Dr. Greg" <greg@enjellic.com>
To: Eric Snowberg <eric.snowberg@oracle.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>,
	keyrings@vger.kernel.org,
	linux-integrity <linux-integrity@vger.kernel.org>,
	David Howells <dhowells@redhat.com>,
	David Woodhouse <dwmw2@infradead.org>,
	dmitry.kasatkin@gmail.com, James Morris <jmorris@namei.org>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	torvalds@linux-foundation.org,
	"Serge E . Hallyn" <serge@hallyn.com>,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	pjones@redhat.com, glin@suse.com,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [RFC PATCH 0/3] Add additional MOK vars
Date: Mon, 24 May 2021 05:09:23 -0500	[thread overview]
Message-ID: <20210524100923.GA29476@wind.enjellic.com> (raw)
In-Reply-To: <4A887886-BDB2-4F88-9D83-73B9BC9E641F@oracle.com>

On Thu, May 20, 2021 at 02:37:31PM -0600, Eric Snowberg wrote:

Good morning, I hope the week is starting well for everyone.

> > On May 19, 2021, at 8:32 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >
> >> After going through the mailing list history related to IMA appraisal, 
> >> is this feature strictly geared towards a custom kernel used for a 
> >> specific purpose?  Do you view it as not being a feature suitable for 
> >> a generic distribution kernel to offer? 
> > 
> > IMA-appraisal is enabled by distros, but requires labeling the
> > filesystem with security.ima xattrs, before loading an appraisal
> > policy.

> I was referring to digital signature based IMA-appraisal.  If a
> company wanted to ship a distro where all immutable files are IMA
> signed, today it would not be feasible.  The end-user will
> undoubtably want to install their own application, but this is not
> possible. The end-user can not IMA sign anything since they do not
> have the ability to add their own IMA CA.

I've spent 6+ years working on this issue, with a focus on trusted
endpoint devices and their communications with trusted cloud
endpoints.

The challenge to trusted systems is that they not only have to be
secure, they have to be tractable for the general development
community to easily target, that is currently not the case.  Eric, as
you note, this extends to the notion of generic Linux distributions
being able to deliver this tractability and flexibility to their user
communities.

Making this happen requires a much more generic system for modeling
security behavior then what currently exists.  If one looks at how
security co-processors are going to evolve, this modeling will end up
going out of the kernel into external devices, which are not going to
be generic TPM's [*].

We have such an architecture for the 5.4 kernel, that with a little
luck, we hope to be able to release by mid-summer.  It peacefully
co-exists with all of the existing integrity infrastructure which
would make it tractable for a value add patch.

It includes a namespace implementation for the security event
modeling, without which, tractable trusted system development is a
non-starter.

If you are interested I will keep you in the loop.

Have a good day.

Greg

[*] We've used SGX enclaves and ST based micro-controller
implementations.

As always,
Dr. Greg Wettstein, Ph.D, Worker      Autonomously self-defensive
Enjellic Systems Development, LLC     IOT platforms and edge devices.
4206 N. 19th Ave.
Fargo, ND  58102
PH: 701-281-1686                      EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"The vast majority of human beings dislike and even dread all notions
 with which they are not familiar.  Hence it comes about that at their
 first appearance innovators have always been derided as fools and
 madmen."
                                -- Aldous Huxley