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=-1.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=unavailable 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 EDBCBC28CC0 for ; Thu, 30 May 2019 19:29:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B8E06260CA for ; Thu, 30 May 2019 19:29:54 +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="iUJd3oa1" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726579AbfE3T3y (ORCPT ); Thu, 30 May 2019 15:29:54 -0400 Received: from mail-lj1-f195.google.com ([209.85.208.195]:45612 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726462AbfE3T3s (ORCPT ); Thu, 30 May 2019 15:29:48 -0400 Received: by mail-lj1-f195.google.com with SMTP id r76so7192090lja.12 for ; Thu, 30 May 2019 12:29:46 -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=iVk/NFNgHVBFx7MhewVcDHKeuh0/y8uv27n+wctjBBw=; b=iUJd3oa19CugyfCed6zmPxPNuarTP/1imCFXfhjAKXmDQBo5jZe7ZBR5RJOq+hx6br tfQzOOPQSqboRyGxFLT3oSfQ+JEgq29U2q60jo8Rr2CFQTVVxATpRL8XEc0KJdCPnkC0 SbiJiRSFkAq8oO5wi8mEi96cPVRUr9w8MIZ/OWqOCcFnsB6CPb5tpIu+P0Ghso3X245/ NCySiboUIcKL8ug8JS2mDcOFFPLquJEQpPTys/6K9z3FovVwTZAdFmLqlzNlKDrXytw1 cQv+DRz6iJnKKRbUgD8k65be4+HNaacB+tw7zitbPLmamQffqA0s+u7+l5fj7cD+yxkk BtIg== 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=iVk/NFNgHVBFx7MhewVcDHKeuh0/y8uv27n+wctjBBw=; b=RB5XYcDVSwiOU7ssT6bn2OoLLPVOdRJsCmkhnWZUGWfuWfPCB4/afjA4/f9XhaOVRK yBN0qqx5B150l2E23BbszgIQUMqRp2OfLhbEWY+pv+IfDgm35HMDcV5B0xhKnYUq+TA7 qcEyIDE9wNLd+gTA2xAH9llqIlZSdEC0SKa4DxsFJkbFPEwsgdOPzegrzCvynQJtZ6kp uQJc1axUdbhgStw20GEXPRyvmEd64BiGUofNFz09Cpz8kBuSogHuEPOD5vZDI86gwNsN SYMkNk8Vqq9PwAB2g6lXQyPNcPQw5y1ED3VJ4Ccr6jzCgXJCexXFZBqnVRuwUxzkfq4j GZGg== X-Gm-Message-State: APjAAAWAtoV69ZExiKPvswVKdmpklIW0AXYBkmKb9Kg91aBpSXux5wuI E05K6nm7h6McJEEnicNjGCEFz8w5kLI8YCLTknyC X-Google-Smtp-Source: APXvYqy4oT9/ncpEwgceU+Uxm1SPfMQyT6tfoJxHZH5OZOJlX84DZdkuPn8yylZ7C5804jX66KJvTV8Txj+BX2224oo= X-Received: by 2002:a2e:9bc5:: with SMTP id w5mr3279775ljj.87.1559244585165; Thu, 30 May 2019 12:29:45 -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> In-Reply-To: <20190530170913.GA16722@mail.hallyn.com> From: Paul Moore Date: Thu, 30 May 2019 15:29:32 -0400 Message-ID: Subject: Re: [PATCH ghak90 V6 02/10] audit: add container id To: "Serge E. Hallyn" Cc: Tycho Andersen , Richard Guy Briggs , 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: netfilter-devel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netfilter-devel@vger.kernel.org On Thu, May 30, 2019 at 1:09 PM Serge E. Hallyn wrote: > On Wed, May 29, 2019 at 06:39:48PM -0400, Paul Moore wrote: > > On Wed, May 29, 2019 at 6:28 PM Tycho Andersen wrote: > > > On Wed, May 29, 2019 at 12:03:58PM -0400, Paul Moore wrote: > > > > On Wed, May 29, 2019 at 11:34 AM Tycho Andersen wrote: > > > > > On Wed, May 29, 2019 at 11:29:05AM -0400, Paul Moore wrote: > > > > > > On Wed, May 29, 2019 at 10:57 AM Tycho Andersen wrote: > > > > > > > On Mon, Apr 08, 2019 at 11:39:09PM -0400, Richard Guy Briggs wrote: ... > > > > > > 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). > > > > > > won't work in user namespaced containers, because they will never be > > > capable(CAP_AUDIT_CONTROL); so I don't think this will work for > > > nesting as is. But maybe nobody cares :) > > > > That's fun :) > > > > To be honest, I've never been a big fan of supporting nested > > containers from an audit perspective, so I'm not really too upset > > about this. The k8s/cri-o folks seem okay with this, or at least I > > haven't heard any objections; lxc folks, what do you have to say? > > I actually thought the answer to this (when last I looked, "some time" ago) > was that userspace should track an audit message saying "task X in > container Y is changing its auditid to Z", and then decide to also track Z. > This should be doable, but a lot of extra work in userspace. > > Per-userns containerids would also work. So task X1 is in containerid > 1 on the host and creates a new task Y in new userns; it continues to > be reported in init_user_ns as containerid 1 forever; but in its own > userns it can request to be known as some other containerid. Audit > socks would be per-userns, allowing root in a container to watch for > audit events in its own (and descendent) namespaces. > > But again I'm sure we've gone over all this in the last few years. > > I suppose we can look at this as a "first step", and talk about > making it user-ns-nestable later. But agreed it's not useful in a > lot of situations as is. [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. Punting this to a LSM hook is an obvious thing to do, and something we might want to do anyway, but currently audit doesn't rely on the LSM for proper/safe operation and I'm not sure I want to change that now. The next obvious thing is to create some sort of access control knob in audit itself. Perhaps an auditctl operation that would allow the administrator to specify which containers, via their corresponding audit container IDs, are allowed to change their audit container ID? The permission granting would need to be done in the init userns, but it would allow containers with a non-init userns the ability to change their audit container ID. We would probably still want a ns_capable(CAP_AUDIT_CONTROL) restriction in this case. Does anyone else have any other ideas? -- paul moore www.paul-moore.com