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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 08D06C76195 for ; Mon, 15 Jul 2019 20:38:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D19DD2145D for ; Mon, 15 Jul 2019 20:38:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=paul-moore-com.20150623.gappssmtp.com header.i=@paul-moore-com.20150623.gappssmtp.com header.b="b5eOePLK" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730693AbfGOUii (ORCPT ); Mon, 15 Jul 2019 16:38:38 -0400 Received: from mail-lj1-f193.google.com ([209.85.208.193]:36871 "EHLO mail-lj1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731021AbfGOUii (ORCPT ); Mon, 15 Jul 2019 16:38:38 -0400 Received: by mail-lj1-f193.google.com with SMTP id z28so17682111ljn.4 for ; Mon, 15 Jul 2019 13:38:37 -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=SPYn0kigh/YyOOP3JdYIDFFrsPtkvgbvu1zMyQDVf3M=; b=b5eOePLKODPIzr8swDyYF4AgFldz7V2YABrA3742nAOHLzAo2/ozBZ0RJ8D5vddpk3 sARlE/+axrtAh0KzWih8Ly0xxU5yIYpkYX1vuY4Ipmgobv3qAB/1jGKDo3KylvK7eHSd 4sJcUaNpn2Mo0wTr/tITuzI5VkAFW1+L/TggkgJyTaDX57KahSyYfLsipraO3VrBagKt 5af5hO2j+xukaou6B0ox1R1O0J8iM7BVCBnKA5cz6PdIvdxQIVHl7YCSpLQAA4Z6I3Z2 jiNXl2hfASd4OE8vuNF//VDxwoQHOiejs0XJsKihnYXyCJwArlLVd3jylh7ferlCZnUf 1LIw== 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=SPYn0kigh/YyOOP3JdYIDFFrsPtkvgbvu1zMyQDVf3M=; b=dltHeOC4imCqQoqBh9Ms3mQ76TAAreW76aodrXBB6BArGGdBNidu5lYOsvs/XqNgnx 65dT4gVCD986DXDbnmFv5YeizscY+GZYp4vZJBC6hTx4xtxsZSFKnDuXKqBeBZlLX9nU vXpJtfbGuYDVY7CBE0Zk2PergeUvZ0lGipHQ9o6ugymXMLAMwc1gkwitMQQIxiDuT4A2 ORBL+roveDzglGRCjJFjBz1vSuPYKOqC4JcJxm/Afw84GnzRiRw4Rn/ZCGeLHa0iIls1 kRAMOEa/QIYtzQUqEltITbo8AsSZARTX96kDscLVOS5926CLr/yjQNTwmVw0U2h05ekm pgtQ== X-Gm-Message-State: APjAAAW7LoVEeVUFq5ScMEp7m9OFpypYrhjw6ZhyE396ydPNbfrjSo3C +eveDoiCPPgvWHf5kwzMwSdOx7rzKkHs0DjFNA== X-Google-Smtp-Source: APXvYqy7ph4w7wyU2yk8+QNPGuKGKilYKae2+aEm11FJ7Oxrse5chHU3V+2dKv4MLJ5f+7kkorTp67H+wXIXoLMuFPs= X-Received: by 2002:a2e:3604:: with SMTP id d4mr15091488lja.85.1563223116334; Mon, 15 Jul 2019 13:38:36 -0700 (PDT) MIME-Version: 1.0 References: <9edad39c40671fb53f28d76862304cc2647029c6.1554732921.git.rgb@redhat.com> <20190529145742.GA8959@cisco> <20190708175105.7zb6mikjw2wmnwln@madcap2.tricolour.ca> In-Reply-To: <20190708175105.7zb6mikjw2wmnwln@madcap2.tricolour.ca> From: Paul Moore Date: Mon, 15 Jul 2019 16:38:25 -0400 Message-ID: Subject: Re: [PATCH ghak90 V6 02/10] audit: add container id To: Richard Guy Briggs Cc: 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 , Serge Hallyn , ebiederm@xmission.com, nhorman@tuxdriver.com Content-Type: text/plain; charset="UTF-8" Sender: netfilter-devel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netfilter-devel@vger.kernel.org On Mon, Jul 8, 2019 at 1:51 PM Richard Guy Briggs wrote: > On 2019-05-29 11:29, Paul Moore wrote: ... > > The idea is that only container orchestrators should be able to > > set/modify the audit container ID, and since setting the audit > > container ID can have a significant effect on the records captured > > (and their routing to multiple daemons when we get there) modifying > > the audit container ID is akin to modifying the audit configuration > > which is why it is gated by CAP_AUDIT_CONTROL. The current thinking > > is that you would only change the audit container ID from one > > set/inherited value to another if you were nesting containers, in > > which case the nested container orchestrator would need to be granted > > CAP_AUDIT_CONTROL (which everyone to date seems to agree is a workable > > compromise). We did consider allowing for a chain of nested audit > > container IDs, but the implications of doing so are significant > > (implementation mess, runtime cost, etc.) so we are leaving that out > > of this effort. > > We had previously discussed the idea of restricting > orchestrators/engines from only being able to set the audit container > identifier on their own descendants, but it was discarded. I've added a > check to ensure this is now enforced. When we weren't allowing nested orchestrators it wasn't necessary, but with the move to support nesting I believe this will be a requirement. We might also need/want to restrict audit container ID changes if a descendant is acting as a container orchestrator and managing one or more audit container IDs; although I'm less certain of the need for this. > I've also added a check to ensure that a process can't set its own audit > container identifier ... What does this protect against, or what problem does this solve? Considering how easy it is to fork/exec, it seems like this could be trivially bypassed. > ... and that if the identifier is already set, then the > orchestrator/engine must be in a descendant user namespace from the > orchestrator that set the previously inherited audit container > identifier. You lost me here ... although I don't like the idea of relying on X namespace inheritance for a hard coded policy on setting the audit container ID; we've worked hard to keep this independent of any definition of a "container" and it would sadden me greatly if we had to go back on that. -- paul moore www.paul-moore.com