archive mirror
 help / color / mirror / Atom feed
From: "Dr. Greg" <>
To: Eric Snowberg <>
Cc: Mimi Zohar <>,,
	linux-integrity <>,
	David Howells <>,
	David Woodhouse <>,, James Morris <>,
	Jarkko Sakkinen <>,,,,
	"Serge E . Hallyn" <>,
	James Bottomley <>,,,
	"" <>
Subject: Re: [RFC PATCH 0/3] Add additional MOK vars
Date: Mon, 24 May 2021 05:09:23 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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 <> 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

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

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

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

Have a good day.


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

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:
"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
                                -- Aldous Huxley

      parent reply	other threads:[~2021-05-24 10:37 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-17 22:57 [RFC PATCH 0/3] Add additional MOK vars Eric Snowberg
2021-05-17 22:57 ` [RFC PATCH 1/3] keys: Add ability to trust the platform keyring Eric Snowberg
2021-05-20 15:59   ` Jarkko Sakkinen
2021-05-17 22:57 ` [RFC PATCH 2/3] keys: Trust platform keyring if MokTrustPlatform found Eric Snowberg
2021-05-17 22:57 ` [RFC PATCH 3/3] ima: Enable IMA SB Policy if MokIMAPolicy found Eric Snowberg
2021-05-19  7:55 ` [RFC PATCH 0/3] Add additional MOK vars Jarkko Sakkinen
2021-05-19 14:32 ` Mimi Zohar
2021-05-19 22:04   ` Eric Snowberg
2021-05-20 12:22     ` Mimi Zohar
2021-05-20 20:37       ` Eric Snowberg
2021-05-21 11:44         ` Mimi Zohar
2021-05-24  0:57           ` Eric Snowberg
2021-05-24 11:12             ` Mimi Zohar
2021-06-01 15:24               ` Eric Snowberg
2021-05-24 10:09         ` Dr. Greg [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).