From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 095C6C433E2 for ; Mon, 14 Sep 2020 17:39:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C75C620EDD for ; Mon, 14 Sep 2020 17:39:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726179AbgINRjA convert rfc822-to-8bit (ORCPT ); Mon, 14 Sep 2020 13:39:00 -0400 Received: from lhrrgout.huawei.com ([185.176.76.210]:2815 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726380AbgINM0L (ORCPT ); Mon, 14 Sep 2020 08:26:11 -0400 Received: from lhreml706-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 18FBB84829DDE50B4086; Mon, 14 Sep 2020 13:07:55 +0100 (IST) Received: from fraeml709-chm.china.huawei.com (10.206.15.37) by lhreml706-chm.china.huawei.com (10.201.108.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 14 Sep 2020 13:07:54 +0100 Received: from lhreml722-chm.china.huawei.com (10.201.108.73) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 14 Sep 2020 14:07:54 +0200 Received: from lhreml722-chm.china.huawei.com ([10.201.108.73]) by lhreml722-chm.china.huawei.com ([10.201.108.73]) with mapi id 15.01.1913.007; Mon, 14 Sep 2020 13:07:53 +0100 From: Krzysztof Struczynski To: Mimi Zohar , Luke Hinds , "Dr. Greg" CC: 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" , "nick.dusek@gmail.com" Subject: RE: [RFC PATCH 00/30] ima: Introduce IMA namespace Thread-Topic: [RFC PATCH 00/30] ima: Introduce IMA namespace Thread-Index: AQHWdXPBkpeRDLdh20+fyp1BiEOjYak+A3mAgBfGuwCABhxpgIABN8iAgAG3kgCACVyMsA== Date: Mon, 14 Sep 2020 12:07:53 +0000 Message-ID: <9ed6fa28510c464a97d4283f6d5b21c5@huawei.com> References: <20200818152037.11869-1-krzysztof.struczynski@huawei.com> <20200818164943.va3um7toztazcfud@wittgenstein> <20200906171413.GA8305@wind.enjellic.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.48.217.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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