Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp602526pxu; Sun, 25 Oct 2020 10:50:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJys9HagrVOY7r2zZPqlB2S35TyXPrdD1LE9eE4TbNyF+d42tlIZPjxCOEDQHeAw5jsSgmjx X-Received: by 2002:a17:906:3950:: with SMTP id g16mr7764769eje.213.1603648228546; Sun, 25 Oct 2020 10:50:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603648228; cv=none; d=google.com; s=arc-20160816; b=hIW5FI8zxmXGw5uTUsden53TmtlEEGNir7cocmCMDdDlMjLxGj+8cHYVMyGzlTqBMc nW0+wxllWa5ql+qbo0cJJqJqBCN7if9pp1rjp63JcaLfF0vhnBt8zCcnMVQKyjKlRMUQ fN6eCp4Yg4WV6+hAVFAdUBN8M55Eg+J88pN5TxR7+Dw5AdOHsaqhh8dxg0zJEgtxzzr1 DmqojJSJ4cyhE78FX9VP4jz3oaSLIFA3vnyU8mdNnuOGnyJ+U0/8LsTgUlwn0swnvwsq 8OVMyfG4EB7QF2putjO2K8agK+otVUxP4ur1wo6sYtZq7iU9ToPRDGMVhKoh93E3gVeJ dgAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:reply-to:message-id:subject:cc:to:from:date; bh=5MNHcc0h3g/x4tO6hO7dc34oMxX7R8bPbW/0PE8T9zA=; b=TvKgY74XQ6hZoy/YWZxC0wqZJMhbMyjg8kN9gFZwvgy+js/JKo1ZY8aFjyCq7HaGjD TrfabQsu46MPPYOkbtiJBwM1VYo/71v1K8PEQ0mEBM0Yu1LjI2vFtilpP5kE0q2cnCEq I+Dj++FneYeBfDf1VZa7vsi9NfjnEZlT6ZxRwbY4TyFJ0VyEEOB3VVNKk7XAYJ9tjFBa ax3BP0i4v/O51lzTR7WNwpnDSNfLLKt0SrR89AmsW6sGjAKfBhcFuhaZ4uCcZuUiWX7O o5GQCm272EqYmv6cDVyA1Cvt0hfU/p1gWFSS4wNRBOdiJEki8PIDPKUUQ51cickRIdvC DxLg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e9si2549130edv.352.2020.10.25.10.49.41; Sun, 25 Oct 2020 10:50:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1416906AbgJYPBj (ORCPT + 99 others); Sun, 25 Oct 2020 11:01:39 -0400 Received: from wind.enjellic.com ([76.10.64.91]:58270 "EHLO wind.enjellic.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1416222AbgJYPBj (ORCPT ); Sun, 25 Oct 2020 11:01:39 -0400 Received: from wind.enjellic.com (localhost [127.0.0.1]) by wind.enjellic.com (8.15.2/8.15.2) with ESMTP id 09PF0ZYl023036; Sun, 25 Oct 2020 10:00:35 -0500 Received: (from greg@localhost) by wind.enjellic.com (8.15.2/8.15.2/Submit) id 09PF0Wg7023035; Sun, 25 Oct 2020 10:00:32 -0500 Date: Sun, 25 Oct 2020 10:00:32 -0500 From: "Dr. Greg" To: Krzysztof Struczynski Cc: Mimi Zohar , Christian Brauner , "linux-integrity@vger.kernel.org" , Linux Kernel Mailing List , "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" , James Morris , "christian@brauner.io" , Silviu Vlasceanu , Roberto Sassu , "ebiederm@xmission.com" , "viro@zeniv.linux.org.uk" , "torvalds@linux-foundation.org" , "luto@amacapital.net" , "jannh@google.com" , Luke Hinds Subject: Re: [RFC PATCH 00/30] ima: Introduce IMA namespace Message-ID: <20201025150031.GA23011@wind.enjellic.com> Reply-To: "Dr. Greg" References: <20200818152037.11869-1-krzysztof.struczynski@huawei.com> <20200818164943.va3um7toztazcfud@wittgenstein> <20200906171413.GA8305@wind.enjellic.com> 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]); Sun, 25 Oct 2020 10:00:35 -0500 (CDT) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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