Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp3234416pxa; Tue, 18 Aug 2020 09:51:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzDe0C7J7PMdTLcz5lX9+m5AqFppZWbmOpXnuulJVDQ+JWzEc4T5JAghotIid1vWqVqNi0n X-Received: by 2002:a17:906:a141:: with SMTP id bu1mr20716943ejb.303.1597769459919; Tue, 18 Aug 2020 09:50:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597769459; cv=none; d=google.com; s=arc-20160816; b=ZXxfojpgIVfkD8MAFl04fF61rlPLAtGFfIrCGrZ/NtXY7oyO5MF3Y6iEGYkkhoonaw XfuLCENcUuwpaDlCmwPl+x7HBkc7n6NKB7rajnxzKUZlwsaB5SBJ+z8M5n91Afi5zVag +BfePTxiX0Ehixlf2mqLb+5fajv/ORJiShiVteSNtmFxcz+r8NJzl0LaFlOscvkow5ao o3UvmPyK/BylqoMZ0qO9JY++9oPzYIY46rqKz4wnLYiNw3yugnyklXW+YPqSUy6RgucU 1F99z2exB53fpsOIvSVO37RXROr35aWibeep3She1pXaiYmp4gffUuJU/X5ndEWRpelF mVuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=xS17cBxHw5rDOlHCddikz0s5VsAPtC9O0bNElLO69ys=; b=MhfqAM3Fm6KyyinCCaGU8nFKnHA6MO7EaSESIIfbbB+gJw0Tx5uSO1tDfyGhOHp59W JH5ZYbkZKb8TppxJ3kaD5y+eRVZf6BAGnOgMEmuG6s7fFJP81AMc2wiBN1tOJihZEE7U IZT0ddk9WS58va0p37gTdgZ7GO7jkQG2k6OF49t49ae+HNA+L9ELeR4KYX6H7Rf5TUry YIHP0nh7laLcUWPNfuHGmzOIwN3kzzxHPdNoTzp065sseZi43G/BehAAcEDiLu6fOrLA G3vdqM8w/rMZkNYqsCNSoXskXfU95pslmflb7TPp9OrBhDcKFgCZ6ZAj2lCW2h0fr5V2 YsMw== 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 d8si13254905ejj.109.2020.08.18.09.50.35; Tue, 18 Aug 2020 09:50:59 -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 S1728352AbgHRQtt (ORCPT + 99 others); Tue, 18 Aug 2020 12:49:49 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:51213 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726715AbgHRQts (ORCPT ); Tue, 18 Aug 2020 12:49:48 -0400 Received: from ip5f5af70b.dynamic.kabel-deutschland.de ([95.90.247.11] helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1k84nw-0000Iz-OU; Tue, 18 Aug 2020 16:49:44 +0000 Date: Tue, 18 Aug 2020 18:49:43 +0200 From: Christian Brauner To: krzysztof.struczynski@huawei.com Cc: linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org, containers@lists.linux-foundation.org, linux-security-module@vger.kernel.org, zohar@linux.ibm.com, stefanb@linux.vnet.ibm.com, sunyuqiong1988@gmail.com, mkayaalp@cs.binghamton.edu, dmitry.kasatkin@gmail.com, serge@hallyn.com, 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 Subject: Re: [RFC PATCH 00/30] ima: Introduce IMA namespace Message-ID: <20200818164943.va3um7toztazcfud@wittgenstein> References: <20200818152037.11869-1-krzysztof.struczynski@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200818152037.11869-1-krzysztof.struczynski@huawei.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 18, 2020 at 05:20:07PM +0200, krzysztof.struczynski@huawei.com wrote: > From: Krzysztof Struczynski > > 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'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? I believe Eric has even pointed that out before. Eric, thoughts? Christian