linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Dr. Greg" <greg@enjellic.com>
To: Luke Hinds <lhinds@redhat.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>,
	Christian Brauner <christian.brauner@ubuntu.com>,
	krzysztof.struczynski@huawei.com,
	linux-integrity@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	containers@lists.linux-foundation.org,
	linux-security-module@vger.kernel.org,
	stefanb@linux.vnet.ibm.com, sunyuqiong1988@gmail.com,
	mkayaalp@cs.binghamton.edu, dmitry.kasatkin@gmail.com,
	"Serge E. Hallyn" <serge@hallyn.com>,
	James Morris <jmorris@namei.org>,
	christian@brauner.io, silviu.vlasceanu@huawei.com,
	roberto.sassu@huawei.com, ebiederm@xmission.com,
	viro@zeniv.linux.org.uk, torvalds@linux-foundation.org,
	luto@amacapital.net, jannh@google.com, nick.dusek@gmail.com
Subject: Re: [RFC PATCH 00/30] ima: Introduce IMA namespace
Date: Wed, 9 Sep 2020 05:11:21 -0500	[thread overview]
Message-ID: <20200909101120.GA16191@wind.enjellic.com> (raw)
In-Reply-To: <CAKrSGQR3Pw=Rad2RgUuCHqr0r2Nc6x2nLoo2cVAkD+_8Vbmd7A@mail.gmail.com>

On Mon, Sep 07, 2020 at 12:50:07PM +0100, Luke Hinds wrote:

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

> On Sun, Sep 6, 2020 at 6:15 PM Dr. Greg <greg@enjellic.com> wrote:
> > Just to be clear, we are not campaigning or advocating what we have
> > done but are simply providing background for discussion.  We haven't
> > campaigned this approach given how complex the kernel development has
> > become, particurlarly with respect to security infrastructure.
> >
> > Candidly, given the politics of security technology being viewed as
> > 'constraining' user rights, I think that a lot of forthcoming security
> > technology may end up being out of tree moving forward.

> I think it's prudent to look forward and plan diligently, but I would not
> want perfect to be the enemy of good.
>
> I approach this more from a user's perspective. We are using IMA in
> https://keylime.dev to measure a host and would like to measure
> within a container too. It's the most common request we hear from
> our users.
>
> Perhaps we all collaborate on a proposal extending Stefans work here:
> https://kernsec.org/wiki/index.php/IMA_Namespacing_design_considerations
>
> I have seen around 3-4 patches now get submitted, so work has been
> done before, and as above, users are present too. We could then have
> some consensus on how this should look and later patches might have
> more success at landing.
>
> Would anyone be interested in this and have recommendations on how
> we could approach this?

Obviously everyone is interested in sharpening their own knives so the
first challenge will be defining where this theme of measurement and
attestation needs to go.

Our focus in all of this is from a platform behavior modeling
perspective.  Our objective is to design platforms/containers that are
capable of self-disciplining themselves in the event that they exhibit
behavior inconsistent with the wishes of their designer.  Container
measurement trivially falls out of this model.

With respect to measurement namespaces, the first problem to be
addressed is what takes custody and responsibility for the measurement
events.  In classic IMA this is, of course, a TPM.  In our model we
use a Trusted Execution Environment (TEE) as this entity.

The TEE makes a decision as to whether or not the kernel should label
a context of execution as being a 'bad actor' if it indicates a desire
to exhibit a behavior inconsistent with a previously defined model.
As I noted previously we have an SGX based solution that provides this
infrastructure but have designed and are moving to a micro-controller
based alternative, given the fact that SGX is now moving to a 'cloud
only' solution.

One of the pain points in all of this appears to be whether or not a
measurement stream from a container should feed into the root
measurement of the platform or be fed into a measurement/monitoring
domain that can be attested against the root measurement of the
platform.  Based on our experiences the latter model is the only one
that is feasible or makes sense from an attestation perspective.

So it would seem that a generic approach to directing the target of
the measurement events would be the first objective.  If there is
interest we can make a copy of our patch available as it supports both
models.

> - Luke

Have a good day.

Dr. Greg

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: dg@enjellic.com
------------------------------------------------------------------------------
"I created a hack to make the division come out right ... I was
 relieved because I thought I was coding wrong.

 Did you?  It took a guy (Thomas Nicely) with a Ph.D. doing heavy
 research in computational number theory to find it, yet you found it
 while working on a game in QuickBasic?"
                                -- Slashdot

      parent reply	other threads:[~2020-09-09 10:12 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <N>
2020-08-18 15:20 ` [RFC PATCH 00/30] ima: Introduce IMA namespace krzysztof.struczynski
2020-08-18 15:20   ` [RFC PATCH 01/30] ima: Introduce ima namespace krzysztof.struczynski
2020-08-18 15:20   ` [RFC PATCH 02/30] ima: Add a list of the installed ima namespaces krzysztof.struczynski
2020-08-18 15:20   ` [RFC PATCH 03/30] ima: Bind ima namespace to the file descriptor krzysztof.struczynski
2020-08-18 15:20   ` [RFC PATCH 04/30] ima: Add ima policy related data to the ima namespace krzysztof.struczynski
2020-08-18 15:20   ` [RFC PATCH 05/30] ima: Add methods for parsing ima policy configuration string krzysztof.struczynski
2020-08-18 15:20   ` [RFC PATCH 06/30] ima: Add ima namespace to the ima subsystem APIs krzysztof.struczynski
2020-08-18 15:20   ` [RFC PATCH 07/30] ima: Extend the APIs in the integrity subsystem krzysztof.struczynski
2020-08-18 15:20   ` [RFC PATCH 08/30] ima: Add integrity inode related data to the ima namespace krzysztof.struczynski
2020-08-18 15:20   ` [RFC PATCH 09/30] ima: Enable per ima namespace policy settings krzysztof.struczynski
2020-08-18 15:53   ` [RFC PATCH 00/30] ima: Introduce IMA namespace Christian Brauner
2020-08-21 15:18     ` Krzysztof Struczynski
2020-08-18 16:19   ` James Bottomley
2020-08-21 15:13     ` Krzysztof Struczynski
2020-09-02 18:53       ` Mimi Zohar
2020-09-04 14:06         ` Dr. Greg
2020-09-14 12:05         ` Krzysztof Struczynski
2020-08-18 16:49   ` Christian Brauner
2020-08-21 15:37     ` Krzysztof Struczynski
2020-09-02 19:54     ` Mimi Zohar
2020-09-06 17:14       ` Dr. Greg
     [not found]         ` <CAKrSGQR3Pw=Rad2RgUuCHqr0r2Nc6x2nLoo2cVAkD+_8Vbmd7A@mail.gmail.com>
2020-09-08 14:03           ` Mimi Zohar
2020-09-14 12:07             ` Krzysztof Struczynski
2020-10-19  9:30             ` Krzysztof Struczynski
2020-10-25 15:00               ` Dr. Greg
2020-09-09 10:11           ` 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20200909101120.GA16191@wind.enjellic.com \
    --to=greg@enjellic.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=christian@brauner.io \
    --cc=containers@lists.linux-foundation.org \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=ebiederm@xmission.com \
    --cc=jannh@google.com \
    --cc=jmorris@namei.org \
    --cc=krzysztof.struczynski@huawei.com \
    --cc=lhinds@redhat.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mkayaalp@cs.binghamton.edu \
    --cc=nick.dusek@gmail.com \
    --cc=roberto.sassu@huawei.com \
    --cc=serge@hallyn.com \
    --cc=silviu.vlasceanu@huawei.com \
    --cc=stefanb@linux.vnet.ibm.com \
    --cc=sunyuqiong1988@gmail.com \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).