Re: [RFC PATCH 00/30] ima: Introduce IMA namespace

Re: [RFC PATCH 00/30] ima: Introduce IMA namespace

[Mimi Zohar]

On Fri, 2020-08-21 at 15:13 +0000, Krzysztof Struczynski wrote:
> > From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com]
> > On Tue, 2020-08-18 at 17:20 +0200, krzysztof.struczynski@huawei.com
> > wrote:
> > > The measurement list remains global, with the assumption that there
> > > is only one TPM in the system. Each IMA namespace has a unique ID,
> > > that allows to track measurements per IMA namespace. Processes in one
> > > namespace, have access only to the measurements from that namespace.
> > > The exception is made for the initial IMA namespace, whose processes
> > > have access to all entries.
> > 
> > So I think this can work in the use case where the system owner is
> > responsible for doing the logging and attestation and the tenants just
> > trust the owner without requiring an attestation.  However, in a multi-
> > tenant system you need a way for the attestation to be per-container
> > (because the combined list of who executed what would be a security
> > leak between tenants).  Since we can't virtualise the PCRs without
> > introducing a vtpm this is going to require a vtpm infrastructure like
> > that used for virtual machines and then we can do IMA logging per
> > container.
> 
> I agree and wonder if we should decouple the attestation trust model,
> which depends on the specific use case (e.g. multi/single tenant,
> public/private cloud), from the IMA logic of linking the measurements to
> the container. Indeed, attestation from within the container might require
> anchoring to a vTPM/vPCR and the current measurement tagging mechanism can
> support several ways of anchoring them to a (virtual) root of trust.
> 
> > I don't think the above has to be in your first patch set, we just have
> > to have an idea of how it could be done to show that nothing in this
> > patch set precludes a follow on from doing this.
> 
> Given that virtualizing trust anchors seems like a separate problem in
> which industry consensus is not easy to reach for all use cases, an
> anchoring mechanism should probably be a separate IMA feature.

Other trust anchors for "trusted keys" has been discussed, but I wasn't
aware of any discussion about other trust anchors for the IMA
measurement list.  The IMA measurement list is very much tied to a TPM.

Including container measurements in the host measurement list, will
unnecessarily cause the host measurement list to grow.  The decision of
what should and shouldn't be included in the host measurement list
shouldn't be defined by the container.

Mimi



_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

Re: [RFC PATCH 00/30] ima: Introduce IMA namespace

[Dr. Greg]

On Wed, Sep 02, 2020 at 02:53:17PM -0400, Mimi Zohar wrote:

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

> On Fri, 2020-08-21 at 15:13 +0000, Krzysztof Struczynski wrote:
> > > From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com]
> > > On Tue, 2020-08-18 at 17:20 +0200, krzysztof.struczynski@huawei.com
> > > wrote:
> > > > The measurement list remains global, with the assumption that there
> > > > is only one TPM in the system. Each IMA namespace has a unique ID,
> > > > that allows to track measurements per IMA namespace. Processes in one
> > > > namespace, have access only to the measurements from that namespace.
> > > > The exception is made for the initial IMA namespace, whose processes
> > > > have access to all entries.
> > > 
> > > So I think this can work in the use case where the system owner is
> > > responsible for doing the logging and attestation and the tenants just
> > > trust the owner without requiring an attestation.  However, in a multi-
> > > tenant system you need a way for the attestation to be per-container
> > > (because the combined list of who executed what would be a security
> > > leak between tenants).  Since we can't virtualise the PCRs without
> > > introducing a vtpm this is going to require a vtpm infrastructure like
> > > that used for virtual machines and then we can do IMA logging per
> > > container.
> > 
> > I agree and wonder if we should decouple the attestation trust model,
> > which depends on the specific use case (e.g. multi/single tenant,
> > public/private cloud), from the IMA logic of linking the measurements to
> > the container. Indeed, attestation from within the container might require
> > anchoring to a vTPM/vPCR and the current measurement tagging mechanism can
> > support several ways of anchoring them to a (virtual) root of trust.
> > 
> > > I don't think the above has to be in your first patch set, we just have
> > > to have an idea of how it could be done to show that nothing in this
> > > patch set precludes a follow on from doing this.
> > 
> > Given that virtualizing trust anchors seems like a separate problem in
> > which industry consensus is not easy to reach for all use cases, an
> > anchoring mechanism should probably be a separate IMA feature.

> Other trust anchors for "trusted keys" has been discussed, but I wasn't
> aware of any discussion about other trust anchors for the IMA
> measurement list.  The IMA measurement list is very much tied to a TPM.
> 
> Including container measurements in the host measurement list, will
> unnecessarily cause the host measurement list to grow.  The decision of
> what should and shouldn't be included in the host measurement list
> shouldn't be defined by the container.

We have been shipping, and more importantly maintaining in the wild,
systems with a namespaced IMA implementation for 4+ years now. We
presented the foundations for all of this at the 2015 Linux Security
Summit in Seattle.

For the purposes of further conversation, I should clarify and
indicate that we have been shipping and maintaining what a namespaced
IMA implementation turns into when all of the engineering challenges
have been addressed with respect to workability issues, particularly
in regards to keeping the resultant system from being too fragile to
be effectively deployed and maintained.

If practical experience is worth anything, I don't believe that
namespacing the current IMA implementation is the optimum path
forward.  With respect to developing operationally relevant trusted
platforms, the objective needs to be modeling the behavior of
namespaces spawned from a known root behavior.

The current IMA implementation provides a great deal of relevant
infrastructure, but as these conversations have suggested, namespacing
the current implementation is problematic given how entangled it has
become with existing kernel infrastructure.  What is needed is
something far simpler that delegates, on the basis of a namespace,
security policy to something other then the kernel, consistent with
what we have learned about policy over the last 29+ years of Linux
development.

With respect to roots of trust, I don't think TPM's/fTPM's, virtual or
otherwise, are going to be the relevant technology moving forward,
although they will be part of the picture.

Mimi has another post down thread that I will provide some more direct
reflections on all of this for whatever value they may have.

> Mimi

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 had far rather walk, as I do, in daily terror of eternity, than feel
 that this was only a children's game in which all of the contestants
 would get equally worthless prizes in the end."
                                -- T. S. Elliot
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

RE: [RFC PATCH 00/30] ima: Introduce IMA namespace

[Krzysztof Struczynski]

> From: Mimi Zohar [mailto:zohar@linux.ibm.com]
> Sent: Wednesday, September 2, 2020 8:53 PM
> > > So I think this can work in the use case where the system owner is
> > > responsible for doing the logging and attestation and the tenants just
> > > trust the owner without requiring an attestation.  However, in a multi-
> > > tenant system you need a way for the attestation to be per-container
> > > (because the combined list of who executed what would be a security
> > > leak between tenants).  Since we can't virtualise the PCRs without
> > > introducing a vtpm this is going to require a vtpm infrastructure like
> > > that used for virtual machines and then we can do IMA logging per
> > > container.
> >
> > I agree and wonder if we should decouple the attestation trust model,
> > which depends on the specific use case (e.g. multi/single tenant,
> > public/private cloud), from the IMA logic of linking the measurements to
> > the container. Indeed, attestation from within the container might require
> > anchoring to a vTPM/vPCR and the current measurement tagging mechanism
> can
> > support several ways of anchoring them to a (virtual) root of trust.
> >
> > > I don't think the above has to be in your first patch set, we just have
> > > to have an idea of how it could be done to show that nothing in this
> > > patch set precludes a follow on from doing this.
> >
> > Given that virtualizing trust anchors seems like a separate problem in
> > which industry consensus is not easy to reach for all use cases, an
> > anchoring mechanism should probably be a separate IMA feature.
> 
> Other trust anchors for "trusted keys" has been discussed, but I wasn't
> aware of any discussion about other trust anchors for the IMA
> measurement list.  The IMA measurement list is very much tied to a TPM.
> 

Agreed. I wouldn't consider anything else than the TPM in the IMA
measurement list context. The anchoring mechanism mentioned above
pertained to the possible extensions of the TPM anchor in the
containerized environment, like the vTPM.

> Including container measurements in the host measurement list, will
> unnecessarily cause the host measurement list to grow.  The decision of
> what should and shouldn't be included in the host measurement list
> shouldn't be defined by the container.
> 

The container has no impact on the measurement list entries other than the
ones related to the processes running within the container. This in turn,
the same as for the original IMA, is defined by the (container's) policy,
loaded on the container's creation.

Best regards,
Krzysztof

> Mimi
> 
> 

_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

Re: [RFC PATCH 00/30] ima: Introduce IMA namespace

[Mimi Zohar]

On Tue, 2020-08-18 at 18:49 +0200, Christian Brauner wrote:
> On Tue, Aug 18, 2020 at 05:20:07PM +0200, krzysztof.struczynski@huawei.com wrote:
> > From: Krzysztof Struczynski <krzysztof.struczynski@huawei.com>
> > 
> > IMA has not been designed to work with containers. It handles every
> > process in the same way, and it cannot distinguish if a process belongs to
> > a container or not.
> > 
> > Containers use namespaces to make it appear to the processes in the
> > containers that they have their own isolated instance of the global
> > resource. For IMA as well, it is desirable to let processes in the
> 
> IMA is brought up on a regular basis with "we want to have this" for
> years and then non-one seems to really care enough.

There is a lot of interest in IMA namespacing, but the question always
comes back to how to enable it.  Refer to  
https://kernsec.org/wiki/index.php/IMA_Namespacing_design_considerations
 for Stefan's analysis.

I understand "containers" is not a kernel construct, but from my very
limited perspective, IMA namespacing only makes sense in the context of
a "container".  The container owner may want to know which files have
been accessed/executed (measurements, remote attestation) and/or
constrain which files may be accessed/executed based on signatures
(appraisal).

> 
> I'm highly skeptical of the value of ~2500 lines of code even if it
> includes a bunch of namespace boilerplate. It's yet another namespace,
> and yet another security framework.
> Why does IMA need to be a separate namespace? Keyrings are tied to user
> namespaces why can't IMA be? 

In the context of a container, the measurement list and IMA/EVM
keyrings need to be setup before the first file is measured, signature
verified, or file hash included in the audit log.

> I believe Eric has even pointed that out
> before.
> 
> Eric, thoughts?

Any help with the above scenario would very be much appreciated.

Mimi

_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

Re: [RFC PATCH 00/30] ima: Introduce IMA namespace

[Dr. Greg]

On Wed, Sep 02, 2020 at 03:54:58PM -0400, Mimi Zohar wrote:

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

A follow on to my previous e-mail regarding what 'namespaced IMA'
should look like.

> On Tue, 2020-08-18 at 18:49 +0200, Christian Brauner wrote:
> > On Tue, Aug 18, 2020 at 05:20:07PM +0200, krzysztof.struczynski@huawei.com wrote:
> > > From: Krzysztof Struczynski <krzysztof.struczynski@huawei.com>
> > > IMA has not been designed to work with containers. It handles
> > > every process in the same way, and it cannot distinguish if a
> > > process belongs to a container or not.
> > >
> > > Containers use namespaces to make it appear to the processes in
> > > the containers that they have their own isolated instance of the
> > > global resource. For IMA as well, it is desirable to let
> > > processes in the

> > IMA is brought up on a regular basis with "we want to have this" for
> > years and then non-one seems to really care enough.

I don't think it is a matter of lack of interest or not caring.  The
challenge becomes whether or not a business case exists for expending
the resources and navigating the challenges needed to advance
infrastructure for inclusion in the kernel.

> There is a lot of interest in IMA namespacing, but the question
> always comes back to how to enable it.  Refer to
> https://kernsec.org/wiki/index.php/IMA_Namespacing_design_considerations
> for Stefan's analysis.

As I noted in my previous e-mail, I believe the path forward is not to
figure out how to address the rather complex and invasive issue of how
to namespace IMA, but instead, needs to be what a flexible
'next-generation' architecture for platform behavioral assessment
looks like.

In a larger context, I believe the future for security is going to
involve at a minimum the kernel, and more likely, something tightly
coupled to the kernel, making active decisions on whether or not a
behavior that the kernel is contemplating mediating is consistent with
platform or container security policy.

To frame this a bit, the well understood role of the kernel with
respect to security is to mediate 'Turing Events', or Actor/Subject
(A/S) interactions.  Both DAC and MAC are based on this concept with
the interface between an Actor and Subject being a security 'gate'.

Given this model, the most simplistic and direct path forward is to
provide a namespace capable method of exporting a description of the
identity parameters that characterize the entities involved in an A/S
interaction.  The kernel, or as I previously suggested as more likely
moving forward, a closely linked entity can then make a decision as to
whether or not the behavior should be allowed.

FWIW, as an example of the minimal impact of this method, here is the
diffstat of such an implementation:

---------------------------------------------------------------------------
 arch/x86/entry/syscalls/syscall_32.tbl    |    2 +
 arch/x86/entry/syscalls/syscall_64.tbl    |    2 +
 fs/proc/array.c                           |    7 +
 fs/proc/namespaces.c                      |    4 +
 include/linux/ima.h                       |   27 +
 include/linux/nsproxy.h                   |    2 +
 include/linux/proc_ns.h                   |    2 +
 include/linux/sched.h                     |    3 +
 include/linux/syscalls.h                  |    6 +
 include/uapi/asm-generic/unistd.h         |    7 +-
 include/uapi/linux/sched.h                |    1 +
 kernel/fork.c                             |    5 +-
 kernel/nsproxy.c                          |   18 +-
 kernel/sys_ni.c                           |    4 +
 security/Kconfig                          |    1 +
 security/Makefile                         |    2 +
 Security/ai/Kconfig                       |   12 +
 security/ai/Makefile                      |    3 +
 security/ai/ai.c                          |  137 ++
 security/integrity/iint.c                 |    5 +
 security/integrity/ima/Makefile           |    2 +-
 security/integrity/ima/ima.h              |   17 +
 security/integrity/ima/ima_api.c          |   37 +-
 security/integrity/ima/ima_fs.c           |   10 +
 security/integrity/ima/ima_identity.c     | 2204 +++++++++++++++++++++++++++++
 security/integrity/ima/ima_init.c         |    6 +-
 security/integrity/ima/ima_main.c         |    7 +
 security/integrity/ima/ima_policy.c       |   74 +-
 security/integrity/ima/ima_queue.c        |   10 +-
 security/integrity/ima/ima_template.c     |    6 +
 security/integrity/ima/ima_template_lib.c |   71 +
 security/integrity/ima/ima_template_lib.h |   10 +
 security/integrity/integrity.h            |    4 +-
 security/security.c                       |    1 +
 34 files changed, 2684 insertions(+), 25 deletions(-)
---------------------------------------------------------------------------

As can be seen, this was built out in the context of the IMA
sub-system with the majority of the changes being encapsulated in one
file.  This includes all of the infrastructure needed for a Trusted
Execution Environment (TEE) to enforce kernel security policy
decisions.

In addition to a container specific representation of the current
behavioral state, each namespace exports via a sysfs pseudo-file, the
following behavioral definition for each A/S interaction.

exchange pid{1} event{cboot:/home/greg/runc} actor{uid=0, euid=0, suid=0, gid=0, egid=0, sgid=0, fsuid=0, fsgid=0, cap=0x3fffffffff} subject{uid=50, gid=50, mode=0100755, name_length=15, name=f0da604ff3f0a3e16163bc9d2f99bb9bcd70397d211b746d0104299972cc5505, s_id=sda1, s_uuid=1bfef8aaa45f4bcaa846640ae4547ddc, digest=791a7cf8dec2afe302836b974b3c0f7b0a5983f76d857aa97658ce09d54f60f8}

Which provides the framework for implementing any number of policy
decisions, of which integrity is only one element.

We had initially used SGX to implement a TEE based enforcement engine,
but given the direction of hardware support, we have largely shelved
our SGX development efforts in favor of using a micro-controller based
approach.

Given what appears to be the direction for mobile devices, a
collection of specialized harware linked by an OS, the notion of a
separate entity making security policy decisions seems relevant.

> I understand "containers" is not a kernel construct, but from my very
> limited perspective, IMA namespacing only makes sense in the context of
> a "container".  The container owner may want to know which files have
> been accessed/executed (measurements, remote attestation) and/or
> constrain which files may be accessed/executed based on signatures
> (appraisal).

Trying to implement supportable and field maintainable 'trusted
computing' is a fools errand without the notion of containerization of
platform behavior.  This is true whether the target is the cloud or
endpoint/IOT class devices.

It seems well understood, that while containers are not a first class
kernel entity, the kernel takes responsibility for implementing
compartmentalization of resources.  It would seem that security event
characterizations are consistent with that model.

In addition, none of this works without developer support.  Framing
behavior assessment in the form of containers means that behavioral
trajectory definitions for the containers can be a byproduct of
standard DEVOP's pipelines.

> > I'm highly skeptical of the value of ~2500 lines of code even if
> > it includes a bunch of namespace boilerplate. It's yet another
> > namespace, and yet another security framework.  Why does IMA need
> > to be a separate namespace? Keyrings are tied to user namespaces
> > why can't IMA be?

> In the context of a container, the measurement list and IMA/EVM
> keyrings need to be setup before the first file is measured,
> signature verified, or file hash included in the audit log.

As I've noted previously, namespacing IMA is problematic, what is
needed is something far simpler and more flexible that provides a
framework for implementing policy outside of the kernel, or if in the
kernel, in a highly customizable fashion.

I think that it would be found that user namespaces bring too much
baggage to the table.  The most effective path forward in this venue
would seem to be to bring forward the most simplistic, flexiable and
uncomplicated mechanism possible.

In this model, classic IMA would serve as a trust root on whose
shoulders a security orchestration framework stands.

> > I believe Eric has even pointed that out before.
> >
> > Eric, thoughts?

> Any help with the above scenario would very be much appreciated.

Hopefully the conversation will benefit from actual field experience
with doing this sort of thing in a supportable fashion.

The concept of 'trusted computing' has been around since the days when
Dave Grawrock designed TXT, which is heavily linked to the heritage of
IMA.  The fact that effective solutions in widespread practice have
not emerged, in the face of demonstrated need, suggests the need to
develop new solution strategies.

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.

> Mimi

Best wishes for a productive week to everyone.

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
------------------------------------------------------------------------------
"A large number of the world's technical challenges have been solved.
 The far greater challenge lies in conveying an understanding of this
 to the world."
                                -- Dr. Greg Wettstein
                                   Resurrection
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

Re: [RFC PATCH 00/30] ima: Introduce IMA namespace

[Luke Hinds]

On Sun, Sep 6, 2020 at 6:15 PM Dr. Greg <greg@enjellic.com> wrote:

> On Wed, Sep 02, 2020 at 03:54:58PM -0400, Mimi Zohar wrote:
>
> Good morning, I hope the weekend is going well for everyone.
>
> A follow on to my previous e-mail regarding what 'namespaced IMA'
> should look like.
>
> > On Tue, 2020-08-18 at 18:49 +0200, Christian Brauner wrote:
> > > On Tue, Aug 18, 2020 at 05:20:07PM +0200,
> krzysztof.struczynski@huawei.com wrote:
> > > > From: Krzysztof Struczynski <krzysztof.struczynski@huawei.com>
> > > > IMA has not been designed to work with containers. It handles
> > > > every process in the same way, and it cannot distinguish if a
> > > > process belongs to a container or not.
> > > >
> > > > Containers use namespaces to make it appear to the processes in
> > > > the containers that they have their own isolated instance of the
> > > > global resource. For IMA as well, it is desirable to let
> > > > processes in the
>
> > > IMA is brought up on a regular basis with "we want to have this" for
> > > years and then non-one seems to really care enough.
>
> I don't think it is a matter of lack of interest or not caring.  The
> challenge becomes whether or not a business case exists for expending
> the resources and navigating the challenges needed to advance
> infrastructure for inclusion in the kernel.
>
> > There is a lot of interest in IMA namespacing, but the question
> > always comes back to how to enable it.  Refer to
> > https://kernsec.org/wiki/index.php/IMA_Namespacing_design_considerations
> > for Stefan's analysis.
>
> As I noted in my previous e-mail, I believe the path forward is not to
> figure out how to address the rather complex and invasive issue of how
> to namespace IMA, but instead, needs to be what a flexible
> 'next-generation' architecture for platform behavioral assessment
> looks like.
>
> In a larger context, I believe the future for security is going to
> involve at a minimum the kernel, and more likely, something tightly
> coupled to the kernel, making active decisions on whether or not a
> behavior that the kernel is contemplating mediating is consistent with
> platform or container security policy.
>
> To frame this a bit, the well understood role of the kernel with
> respect to security is to mediate 'Turing Events', or Actor/Subject
> (A/S) interactions.  Both DAC and MAC are based on this concept with
> the interface between an Actor and Subject being a security 'gate'.
>
> Given this model, the most simplistic and direct path forward is to
> provide a namespace capable method of exporting a description of the
> identity parameters that characterize the entities involved in an A/S
> interaction.  The kernel, or as I previously suggested as more likely
> moving forward, a closely linked entity can then make a decision as to
> whether or not the behavior should be allowed.
>
> FWIW, as an example of the minimal impact of this method, here is the
> diffstat of such an implementation:
>
> ---------------------------------------------------------------------------
>  arch/x86/entry/syscalls/syscall_32.tbl    |    2 +
>  arch/x86/entry/syscalls/syscall_64.tbl    |    2 +
>  fs/proc/array.c                           |    7 +
>  fs/proc/namespaces.c                      |    4 +
>  include/linux/ima.h                       |   27 +
>  include/linux/nsproxy.h                   |    2 +
>  include/linux/proc_ns.h                   |    2 +
>  include/linux/sched.h                     |    3 +
>  include/linux/syscalls.h                  |    6 +
>  include/uapi/asm-generic/unistd.h         |    7 +-
>  include/uapi/linux/sched.h                |    1 +
>  kernel/fork.c                             |    5 +-
>  kernel/nsproxy.c                          |   18 +-
>  kernel/sys_ni.c                           |    4 +
>  security/Kconfig                          |    1 +
>  security/Makefile                         |    2 +
>  Security/ai/Kconfig                       |   12 +
>  security/ai/Makefile                      |    3 +
>  security/ai/ai.c                          |  137 ++
>  security/integrity/iint.c                 |    5 +
>  security/integrity/ima/Makefile           |    2 +-
>  security/integrity/ima/ima.h              |   17 +
>  security/integrity/ima/ima_api.c          |   37 +-
>  security/integrity/ima/ima_fs.c           |   10 +
>  security/integrity/ima/ima_identity.c     | 2204
> +++++++++++++++++++++++++++++
>  security/integrity/ima/ima_init.c         |    6 +-
>  security/integrity/ima/ima_main.c         |    7 +
>  security/integrity/ima/ima_policy.c       |   74 +-
>  security/integrity/ima/ima_queue.c        |   10 +-
>  security/integrity/ima/ima_template.c     |    6 +
>  security/integrity/ima/ima_template_lib.c |   71 +
>  security/integrity/ima/ima_template_lib.h |   10 +
>  security/integrity/integrity.h            |    4 +-
>  security/security.c                       |    1 +
>  34 files changed, 2684 insertions(+), 25 deletions(-)
> ---------------------------------------------------------------------------
>
> As can be seen, this was built out in the context of the IMA
> sub-system with the majority of the changes being encapsulated in one
> file.  This includes all of the infrastructure needed for a Trusted
> Execution Environment (TEE) to enforce kernel security policy
> decisions.
>
> In addition to a container specific representation of the current
> behavioral state, each namespace exports via a sysfs pseudo-file, the
> following behavioral definition for each A/S interaction.
>
> exchange pid{1} event{cboot:/home/greg/runc} actor{uid=0, euid=0, suid=0,
> gid=0, egid=0, sgid=0, fsuid=0, fsgid=0, cap=0x3fffffffff} subject{uid=50,
> gid=50, mode=0100755, name_length=15,
> name=f0da604ff3f0a3e16163bc9d2f99bb9bcd70397d211b746d0104299972cc5505,
> s_id=sda1, s_uuid=1bfef8aaa45f4bcaa846640ae4547ddc,
> digest=791a7cf8dec2afe302836b974b3c0f7b0a5983f76d857aa97658ce09d54f60f8}
>
> Which provides the framework for implementing any number of policy
> decisions, of which integrity is only one element.
>
> We had initially used SGX to implement a TEE based enforcement engine,
> but given the direction of hardware support, we have largely shelved
> our SGX development efforts in favor of using a micro-controller based
> approach.
>
> Given what appears to be the direction for mobile devices, a
> collection of specialized harware linked by an OS, the notion of a
> separate entity making security policy decisions seems relevant.
>
> > I understand "containers" is not a kernel construct, but from my very
> > limited perspective, IMA namespacing only makes sense in the context of
> > a "container".  The container owner may want to know which files have
> > been accessed/executed (measurements, remote attestation) and/or
> > constrain which files may be accessed/executed based on signatures
> > (appraisal).
>
> Trying to implement supportable and field maintainable 'trusted
> computing' is a fools errand without the notion of containerization of
> platform behavior.  This is true whether the target is the cloud or
> endpoint/IOT class devices.
>
> It seems well understood, that while containers are not a first class
> kernel entity, the kernel takes responsibility for implementing
> compartmentalization of resources.  It would seem that security event
> characterizations are consistent with that model.
>
> In addition, none of this works without developer support.  Framing
> behavior assessment in the form of containers means that behavioral
> trajectory definitions for the containers can be a byproduct of
> standard DEVOP's pipelines.
>
> > > I'm highly skeptical of the value of ~2500 lines of code even if
> > > it includes a bunch of namespace boilerplate. It's yet another
> > > namespace, and yet another security framework.  Why does IMA need
> > > to be a separate namespace? Keyrings are tied to user namespaces
> > > why can't IMA be?
>
> > In the context of a container, the measurement list and IMA/EVM
> > keyrings need to be setup before the first file is measured,
> > signature verified, or file hash included in the audit log.
>
> As I've noted previously, namespacing IMA is problematic, what is
> needed is something far simpler and more flexible that provides a
> framework for implementing policy outside of the kernel, or if in the
> kernel, in a highly customizable fashion.
>
> I think that it would be found that user namespaces bring too much
> baggage to the table.  The most effective path forward in this venue
> would seem to be to bring forward the most simplistic, flexiable and
> uncomplicated mechanism possible.
>
> In this model, classic IMA would serve as a trust root on whose
> shoulders a security orchestration framework stands.
>
> > > I believe Eric has even pointed that out before.
> > >
> > > Eric, thoughts?
>
> > Any help with the above scenario would very be much appreciated.
>
> Hopefully the conversation will benefit from actual field experience
> with doing this sort of thing in a supportable fashion.
>
> The concept of 'trusted computing' has been around since the days when
> Dave Grawrock designed TXT, which is heavily linked to the heritage of
> IMA.  The fact that effective solutions in widespread practice have
> not emerged, in the face of demonstrated need, suggests the need to
> develop new solution strategies.
>
> 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?

- Luke


> Mimi
>
> Best wishes for a productive week to everyone.
>
> 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
>
> ------------------------------------------------------------------------------
> "A large number of the world's technical challenges have been solved.
>  The far greater challenge lies in conveying an understanding of this
>  to the world."
>                                 -- Dr. Greg Wettstein
>                                    Resurrection
>
>
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

Re: [RFC PATCH 00/30] ima: Introduce IMA namespace

[Mimi Zohar]

On Mon, 2020-09-07 at 12:50 +0100, Luke Hinds wrote:
> > 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.

Agreed.  This isn't an abstract problem, but one that has already come
up and, hopefully, has been addressed appropriately.

> 
> 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_considerati
> ons
> 
> 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?

When Roberto Sassu and Krzysztof Struczynski contacted me about the
status of Stefan Berger's patch set, based on Yuqiong Sun's work, I was
under the impression that they would be rebasing it on the latest
kernel and going forward from there.   Obviously things changed.  I
pointed out to them resolving the "IMA namespacing" issue would be the
first thing that needs to be addressed.  So here we are.

Definitely, let's have this discussion.

Mimi

_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

RE: [RFC PATCH 00/30] ima: Introduce IMA namespace

[Krzysztof Struczynski]

> From: Mimi Zohar [mailto:zohar@linux.ibm.com]
> Sent: Tuesday, September 8, 2020 4:03 PM
> > > 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.
> 
> Agreed.  This isn't an abstract problem, but one that has already come
> up and, hopefully, has been addressed appropriately.
> 
> >
> > 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_considerati
> > ons
> >
> > 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?
> 
> When Roberto Sassu and Krzysztof Struczynski contacted me about the
> status of Stefan Berger's patch set, based on Yuqiong Sun's work, I was
> under the impression that they would be rebasing it on the latest
> kernel and going forward from there.   Obviously things changed.  I
> pointed out to them resolving the "IMA namespacing" issue would be the
> first thing that needs to be addressed.  So here we are.
> 

The concept of the IMA namespace as a separate namespace, not attached to
the user or mount namespace, remains the same as in the last set of
Stefan's patches. The creation and configuration mechanism changed,
partially because of the changes in the upstream kernel like extension of
the CLONE_ flags, that facilitated other solutions. The main inspiration
in this regard was the new time namespace.

The implemented mechanism is intended to make the configuration of the IMA
namespace as similar as possible to the upstream IMA implementation and
allows to configure the new IMA namespace before any process enters that
namespace, so the very first actions can be measured/appraised/audited.

In this implementation many design points formulated by Stefan still stand.
The significant difference in the presented design is the threat model.
The actions of the host's root and any other user within the container are
measured/appraised/audited according to the container's policy. However,
every action that affects objects in the root namespace, is detected when
processes from the root namespace access them.

Best regards,
Krzysztof

> Definitely, let's have this discussion.
> 
> Mimi

_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

RE: [RFC PATCH 00/30] ima: Introduce IMA namespace

[Krzysztof Struczynski]

> From: Krzysztof Struczynski
> Sent: Monday, September 14, 2020 2:08 PM
> > When Roberto Sassu and Krzysztof Struczynski contacted me about the
> > status of Stefan Berger's patch set, based on Yuqiong Sun's work, I was
> > under the impression that they would be rebasing it on the latest
> > kernel and going forward from there.   Obviously things changed.  I
> > pointed out to them resolving the "IMA namespacing" issue would be the
> > first thing that needs to be addressed.  So here we are.
> >
> 
> The concept of the IMA namespace as a separate namespace, not attached to
> the user or mount namespace, remains the same as in the last set of
> Stefan's patches. The creation and configuration mechanism changed,
> partially because of the changes in the upstream kernel like extension of
> the CLONE_ flags, that facilitated other solutions. The main inspiration
> in this regard was the new time namespace.
> 
> The implemented mechanism is intended to make the configuration of the
> IMA
> namespace as similar as possible to the upstream IMA implementation and
> allows to configure the new IMA namespace before any process enters that
> namespace, so the very first actions can be measured/appraised/audited.
> 
> In this implementation many design points formulated by Stefan still stand.
> The significant difference in the presented design is the threat model.
> The actions of the host's root and any other user within the container are
> measured/appraised/audited according to the container's policy. However,
> every action that affects objects in the root namespace, is detected when
> processes from the root namespace access them.

Do you think that the above proposal addresses the aforementioned "IMA
namespacing" issue? If it doesn't, would you please clarify what are the
main, outstanding problems?
 
> > Definitely, let's have this discussion.

Shall we continue the discussion here, or in addition use a format similar
to the Stefan's "drawing board":
https://kernsec.org/wiki/index.php/IMA_Namespacing_design_considerations

Best regards,
Krzysztof Struczynski
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

Re: [RFC PATCH 00/30] ima: Introduce IMA namespace

[Dr. Greg]

On Mon, Oct 19, 2020 at 09:30:27AM +0000, Krzysztof Struczynski wrote:

Good morning, I hope this note finds the weekend going well for
everyone.

> > The concept of the IMA namespace as a separate namespace, not
> > attached to the user or mount namespace, remains the same as in
> > the last set of Stefan's patches. The creation and configuration
> > mechanism changed, partially because of the changes in the
> > upstream kernel like extension of the CLONE_ flags, that
> > facilitated other solutions. The main inspiration in this regard
> > was the new time namespace.
> >
> > The implemented mechanism is intended to make the configuration of
> > the IMA namespace as similar as possible to the upstream IMA
> > implementation and allows to configure the new IMA namespace
> > before any process enters that namespace, so the very first
> > actions can be measured/appraised/audited.
> >
> > In this implementation many design points formulated by Stefan
> > still stand.  The significant difference in the presented design
> > is the threat model.  The actions of the host's root and any other
> > user within the container are measured/appraised/audited according
> > to the container's policy. However, every action that affects
> > objects in the root namespace, is detected when processes from the
> > root namespace access them.

> Do you think that the above proposal addresses the aforementioned
> "IMA namespacing" issue? If it doesn't, would you please clarify
> what are the main, outstanding problems?

From our perspective, a significant objective of the namespacing
discussion needs to be considerations regarding how additional growth
and sophistication of IMA as a sub-system will occur.

IMA, if taken to its limit, resolves into the notion of modeling the
behavior of a hardware platform, its operating system and the
supported application stack.  We believe the most important issue with
respect to namespacing is to provide an opportunity to allow more
sophisticated and capable models to be developed and implemented,
without having the process unduely constrained by the realities of
kernel development.

Coupled with this issue is the fact that it doesn't seem reasonable to
believe that TPM's are going to be the venue or root of trust for this
modeling, for a variety of reasons, perhaps most principally the fact
that they are a 'blackbox' that have not enjoyed universal trust.
This is perhaps particularly relevant now that they are being
implemented in firmware rather then actual hardware.

The sophistication and security capabilities of micro-controllers that
are being developed for the IOT security space make a case for
developing open-source/architecture security co-processors that
implement the modeling and root of trust for independent modeling/IMA
namespaces.

TPM's also implicitly constrain the modeling to be a function based on
linear extension summing.  It seems pretty clear that stochastic as
well as deterministic models will be needed, particularly for more
dynamic systems.

So the optimum approach would seem to be for the namespace to have the
option of implementing its own policy or to provide a mechanism for
forwarding all of the Turing event characteristics to an entity that
can implement the desired integrity or model policy.

All of this would also seem to be consistent with the direction of the
mobile market, which appears to be moving toward a model of an
operating system that binds together multiple co-processors or
functional units.  IMA, in this model, is a separate functional entity
resonsible for interpreting and disciplining kernel behavior.

> > > Definitely, let's have this discussion.

> Shall we continue the discussion here, or in addition use a format similar
> to the Stefan's "drawing board":
> https://kernsec.org/wiki/index.php/IMA_Namespacing_design_considerations

It has always been said that code speaks louder then words.  So we are
working through the process of cleaning up our implementation of the
approach described above so that people can at least take a look at
the architecture we are proposing.

We don't have any belief that it would be suitable to survive the
gauntlet of the kernel development process but we will offer it as a
proof of concept of where we think all of this will, can and needs to
end up going.

We were able to bolt all of this on top of standard IMA in a
reasonably straight forward fashion.  Our initial implementation of an
external modeling engine was based on SGX, which was remarkably useful
for this purpose, albeit not well understood.

Given the trajectory that technology has been placed on, we now have
an implementation based on an ARM micro-controller as the external
modeling/policy engine.  While not quite as flexible as the SGX based
approach it has a number of its own advantages, most principally
ubiquity of implementation.  Both approaches required no modification
of the namespaced IMA implementation which we believe speaks to the
flexibility of the approach.

> Best regards,
> Krzysztof Struczynski

Hopefully the above reflections are helpful in steering progress of
discussions, if not the price was certainly right.

Best wishes for a productive week to everyone.

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: greg@enjellic.com
------------------------------------------------------------------------------
"Attendants at a service station in Eunice, Louisiana, handed more than
 $100 to a naked man who claimed to have a gun in his pocket."
                                -- Unknown
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

Re: [RFC PATCH 00/30] ima: Introduce IMA namespace

[Dr. Greg]

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
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers