Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp4742673ybi; Mon, 15 Jul 2019 14:05:22 -0700 (PDT) X-Google-Smtp-Source: APXvYqwVFAFOKHYRofZwF4CJv46FLz3Ui9budRP/lmjsdv+SCXG5Bn5DLddejwF8iu7cWsXVeI3G X-Received: by 2002:a63:b1d:: with SMTP id 29mr29079605pgl.103.1563224722196; Mon, 15 Jul 2019 14:05:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563224722; cv=none; d=google.com; s=arc-20160816; b=OlEmK+V9PkjP65/VGCdedAn29xQD/nw+4P7L685ZUtM4M49z4SFZBK327a3hz0cU6S BmPt4VATQy+0v7YyM3V9YVw+4pIStSMYKX/HZZcha/VeArEqNitR9GYnUiCco5j0yaXH N+JyvGOmdS6xq8x5EGWJnc4laoO/k0kmeUum3ITnh+wUuctTZc8qV3rkLl5x8kdsJe8W Gs+ztL6whZfeBrhPsAYUPrYWXibqgcDwgj5KN2O+2rU1HZ9wpGHMYRC+JQL8E8eqepWR UMeknbZeovdJaDY5jgB/fwOTpWU9GSN/+bOo/+OiCEeAABbMa78k8TM37tfY0h7mbXtx 4Wvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=nMdAH6nTLDrGvTqGSOAbQkcOJz7RylQFzwai+/2x5Kg=; b=PDgpPDSfknwcT/1qJixjStM6I+gbvd63t7lITJJk9mFYn4vV5v0mX98tRDvDhC+Z8F DuS131hLEFmHUPFzH/Lh9Np2X/1/W9OuLciWkhTsw6G3/r/rFtDCimkC9yy+UtbGxH5E lNzU9erh/X2BuubsE/awclOo33XX3nq811wSMm/Ew20JbXTiK/zT4jAvZWKBmSM3Cx+Z ozClr6zjmIOwODmzH8b670SDO5qmzUjWDyWZm4lhWb9QRuPvAeWJi8LbB1qj2styamHj aWPWba/Dg/pK0R+AlXdL4IP9dws1RkWYKMO5DPjLpCZemRX7s6R5AaDoG2ZvV6VG4AFJ d20w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b="C00/OWh9"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h11si16085212plr.34.2019.07.15.14.05.05; Mon, 15 Jul 2019 14:05:22 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b="C00/OWh9"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729640AbfGOVEo (ORCPT + 99 others); Mon, 15 Jul 2019 17:04:44 -0400 Received: from mail-lj1-f195.google.com ([209.85.208.195]:41785 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731927AbfGOVEn (ORCPT ); Mon, 15 Jul 2019 17:04:43 -0400 Received: by mail-lj1-f195.google.com with SMTP id d24so17706797ljg.8 for ; Mon, 15 Jul 2019 14:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nMdAH6nTLDrGvTqGSOAbQkcOJz7RylQFzwai+/2x5Kg=; b=C00/OWh9vq2MRiQn1E4VUuP+O+05mZjNiBnTBYE91LA3zA6l01Y3ZAFqD2sa2HJkYA h5J92fYmst8NEM4kbY7z9ANwjGbMbqg3KDgovAqdXLcZH01wV9eGew+ThGgGmvphgmAD MxCVdar45y7UYA1DDtDoQVv8dYq4cWtZjZQ6/WT8LjTbkRr544wt+KFFducPNhPYqfvf wvewvBAHmtMQ3UdggObhYJdHU1TEreaMfaoyjsOy6hYFNOwCZ9YqhCLMTU3973yjiSJE Yi+PlsVJ+lpWQCfj+ktNFR7xMaZJmXQJhqz9OR+Yp0H3xtV8sPxtgsA5H5qa8lTtOAmU 09Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nMdAH6nTLDrGvTqGSOAbQkcOJz7RylQFzwai+/2x5Kg=; b=h2tucWc2pWYo3bHk7JCAtsQxy+7M3tnxC2bHcChkuYl2CpnRG+Bt9SflLYgj8/0E6n OF12jlFE2ovyuBbkdL43Gw5l+Pboa6k6/AHZuXzH0B09lFEa0Txj1qX40U7+zMivbD74 JafshMjQ0pb8fWE3iJvnM5QGHvuLsqfbJyVpB4wr+8LFRY5mSViF4lH4yUQPFqhD2GqA PHg4WuUnFBOFEwkCeYoGTDcp3WDHySjv7vpQG67vhfPULGeobeK/dPIbtrNKXXvVaDpe llO0KcWNG3Ihf1xEwvGg0WeKTSqBHBIuvpawSq0rlv98tuQ7UROfrTGkn81rlVohqQjc f1eQ== X-Gm-Message-State: APjAAAUUwYp/qHkvDhm4jpfg9Fz2Pj1diSvAdCMW45Ao/8VHkREMkPkQ N1GHFV9XyEb7msLrtdi0uRESea89MGcRGXpi0A== X-Received: by 2002:a2e:5bdd:: with SMTP id m90mr14605368lje.46.1563224680729; Mon, 15 Jul 2019 14:04:40 -0700 (PDT) MIME-Version: 1.0 References: <9edad39c40671fb53f28d76862304cc2647029c6.1554732921.git.rgb@redhat.com> <20190529145742.GA8959@cisco> <20190529153427.GB8959@cisco> <20190529222835.GD8959@cisco> <20190530170913.GA16722@mail.hallyn.com> <20190708180558.5bar6ripag3sdadl@madcap2.tricolour.ca> In-Reply-To: <20190708180558.5bar6ripag3sdadl@madcap2.tricolour.ca> From: Paul Moore Date: Mon, 15 Jul 2019 17:04:29 -0400 Message-ID: Subject: Re: [PATCH ghak90 V6 02/10] audit: add container id To: Richard Guy Briggs Cc: "Serge E. Hallyn" , Tycho Andersen , containers@lists.linux-foundation.org, linux-api@vger.kernel.org, Linux-Audit Mailing List , linux-fsdevel@vger.kernel.org, LKML , netdev@vger.kernel.org, netfilter-devel@vger.kernel.org, sgrubb@redhat.com, omosnace@redhat.com, dhowells@redhat.com, simo@redhat.com, Eric Paris , ebiederm@xmission.com, nhorman@tuxdriver.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 8, 2019 at 2:06 PM Richard Guy Briggs wrote: > On 2019-05-30 15:29, Paul Moore wrote: ... > > [REMINDER: It is an "*audit* container ID" and not a general > > "container ID" ;) Smiley aside, I'm not kidding about that part.] > > > > I'm not interested in supporting/merging something that isn't useful; > > if this doesn't work for your use case then we need to figure out what > > would work. It sounds like nested containers are much more common in > > the lxc world, can you elaborate a bit more on this? > > > > As far as the possible solutions you mention above, I'm not sure I > > like the per-userns audit container IDs, I'd much rather just emit the > > necessary tracking information via the audit record stream and let the > > log analysis tools figure it out. However, the bigger question is how > > to limit (re)setting the audit container ID when you are in a non-init > > userns. For reasons already mentioned, using capable() is a non > > starter for everything but the initial userns, and using ns_capable() > > is equally poor as it essentially allows any userns the ability to > > munge it's audit container ID (obviously not good). It appears we > > need a different method for controlling access to the audit container > > ID. > > We're not quite ready yet for multiple audit daemons and possibly not > yet for audit namespaces, but this is starting to look a lot like the > latter. A few quick comments on audit namespaces: the audit container ID is not envisioned as a new namespace (even in nested form) and neither do I consider running multiple audit daemons to be a new namespace. From my perspective we create namespaces to allow us to redefine a global resource for some subset of the system, e.g. providing a unique /tmp for some number of processes on the system. While it may be tempting to think of the audit container ID as something we could "namespace", especially when multiple audit daemons are concerned, in some ways this would be counter productive; the audit container ID is intended to be a global ID that can be used to associate audit event records with a "container" where the "container" is defined by an orchestrator outside the audit subsystem. The global nature of the audit container ID allows us to maintain a sane(ish) view of the system in the audit log, if we were to "namespace" the audit container ID such that the value was no longer guaranteed to be unique throughout the system, we would need to additionally track the audit namespace along with the audit container ID which starts to border on insanity IMHO. > If we can't trust ns_capable() then why are we passing on > CAP_AUDIT_CONTROL? It is being passed down and not stripped purposely > by the orchestrator/engine. If ns_capable() isn't inherited how is it > gained otherwise? Can it be inserted by cotainer image? I think the > answer is "no". Either we trust ns_capable() or we have audit > namespaces (recommend based on user namespace) (or both). My thinking is that since ns_capable() checks the credentials with respect to the current user namespace we can't rely on it to control access since it would be possible for a privileged process running inside an unprivileged container to manipulate the audit container ID (containerized process has CAP_AUDIT_CONTROL, e.g. running as root in the container, while the container itself does not). > At this point I would say we are at an impasse unless we trust > ns_capable() or we implement audit namespaces. I'm not sure how we can trust ns_capable(), but if you can think of a way I would love to hear it. I'm also not sure how namespacing audit is helpful (see my above comments), but if you think it is please explain. > I don't think another mechanism to trust nested orchestrators/engines > will buy us anything. > > Am I missing something? Based on your questions/comments above it looks like your understanding of ns_capable() does not match mine; if I'm thinking about ns_capable() incorrectly, please educate me. -- paul moore www.paul-moore.com