Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp1189673ybx; Thu, 31 Oct 2019 07:01:30 -0700 (PDT) X-Google-Smtp-Source: APXvYqzMqzMhonmSoRQT0aKtF5MUXa718Q0xVmTQONlY/h9L7FncB0CagFwRwt+05b60DYNmbZyq X-Received: by 2002:a05:651c:303:: with SMTP id a3mr4111632ljp.55.1572530489901; Thu, 31 Oct 2019 07:01:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572530489; cv=none; d=google.com; s=arc-20160816; b=LAIQMbzPIMXIeEG0bhf/vxRJPjuVjVBbGosQ/zBmLUM0BNpXfA00WsMhOF/7dSww4t 0guXpxo7sJBplcVCW/Jx3gIrhlKYjO8UN98aOLc3I81yLbWQkNoh29vctbVgGilDq93I Uji424lyGoSFf1IhAgNmBAXf46grSLVt5hJ5hL9A5zkjLeayx0Q/NDF0bK4P/0BQGDg1 Hi6mAK1OFcHuf9oQat/EzXNiVUUv94QUGrqK79h+zivBhSBD4thU837BUPeVH7M8QlpO MqVp663vTeYKQdKT3KABgCnqYyj0O6AKBE0d1p2pJpfZQBov7tYmemn5VWyMfyRYXEX4 9HdA== 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=DuatfVoIRwFhp1fiwVqEQDhLv5NKcD5+eL4mURteBJw=; b=0lD3Q6O2VdIKP5ZaDRD9edB6jDBA+liCVKP4ZXpiEB1qOg9RbI5L2nWdM9g00SzBXj 2FuBYXfm0yz2ebO5UuDrnEJRw1iFa9k/BeXBUqqp3wNLKU5olI9dH0pTdNPYcm67B7U3 MwcjklTJ+dQkrT+Tm/BCYciTWn/7vNREnzUtM29vKlcKoHroX+ESFfDj2fyTAikB1+y7 N9wUmXbyruS4FKW+nBi755Ar1pvznZdDVV1A1mGTWvVd+bsTEZfk3D4oHudwNuDSC4iR iBnP7Bgi8ZGdGTvpl7PuA0m1OQMraESrHesZH/zYnt1YoPPhty1nkyQzcW0aY0zzkfcm qP7A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=T0WGQpXF; 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 m19si3937831ejd.180.2019.10.31.07.01.04; Thu, 31 Oct 2019 07:01:29 -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=T0WGQpXF; 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 S1727922AbfJaOAE (ORCPT + 99 others); Thu, 31 Oct 2019 10:00:04 -0400 Received: from mail-lj1-f193.google.com ([209.85.208.193]:45139 "EHLO mail-lj1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727902AbfJaOAD (ORCPT ); Thu, 31 Oct 2019 10:00:03 -0400 Received: by mail-lj1-f193.google.com with SMTP id q64so6697323ljb.12 for ; Thu, 31 Oct 2019 07:00:01 -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=DuatfVoIRwFhp1fiwVqEQDhLv5NKcD5+eL4mURteBJw=; b=T0WGQpXFDtrHJfxqFmxbHxIc4bAH6IQvZs0OTPR85eE1GuPEBycmk9QZ+dEad3gcBZ 111Tl8gHMDWobnSVm/oAzghXtZ67XKZeU7Iv1i1wit1eJeMjOr73oWKibGez8sYJXCg5 +cQOCUohhdbNghmuNdLDmn228db2gz+xBmkAIvJqZTSY4dHUXeEEkpIrb7ncIQmqboAt Z/ov5p25AUY1THMKi1DviI/uX3DGy8zd/T97zX+udzdtsfjL4srz+5gXsM7b01LCQpzv BX6g51anf+KwtwI58WA9i6Uh/aOtyToAeS5ZFqybf4ztcFcPzqIgUxpnTGSLbS4pEaEu btAg== 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=DuatfVoIRwFhp1fiwVqEQDhLv5NKcD5+eL4mURteBJw=; b=Da0tqY9K6hyRMpzDd2E5JwtGs2KpeEYs55guKX8SkM4SG92mgQc180puFR4mz9JMnL ySbR6zKuAhtoC/pbGuPSFJjHW4dZE68U0BPI0dTE01IN7QHUq+O4DlDKF2HB+OlLZ9h/ AzpfeUeM8zZsiBDQTUe9lRgZXEPu1/I897/nLj8KEToTaiyV+siOu4PjZyUlmcJ6fRb5 gxbsDbMk0jZ8OhcsP+AYFagQe2eEgb+TgvLIEeHYJdkYQXEG8zYh02xokzBttcQITEIx mnhoaJBq1a94Ru+aPDzWA6I21ZZgir+E0OXawgu0wS35tpu4pV8EuNALn2L/ABKFlOe3 SV8w== X-Gm-Message-State: APjAAAUeCIPUG5hg+ZADKBaDUo9Om8Yn8QW61LFnmVyR7ZpbF2vH7FQw fO+MsqELiAEYyi7gQvZvbPFEpucocJltOBJLmb04 X-Received: by 2002:a05:651c:1056:: with SMTP id x22mr1097948ljm.225.1572530400425; Thu, 31 Oct 2019 07:00:00 -0700 (PDT) MIME-Version: 1.0 References: <214163d11a75126f610bcedfad67a4d89575dc77.1568834525.git.rgb@redhat.com> <20191019013904.uevmrzbmztsbhpnh@madcap2.tricolour.ca> <20191021213824.6zti5ndxu7sqs772@madcap2.tricolour.ca> <20191021235734.mgcjotdqoe73e4ha@madcap2.tricolour.ca> <20191024210010.owwgc3bqbvtdsqws@madcap2.tricolour.ca> <20191030220320.tnwkaj5gbzchcn7j@madcap2.tricolour.ca> In-Reply-To: <20191030220320.tnwkaj5gbzchcn7j@madcap2.tricolour.ca> From: Paul Moore Date: Thu, 31 Oct 2019 09:59:48 -0400 Message-ID: Subject: Re: [PATCH ghak90 V7 20/21] audit: add capcontid to set contid outside init_user_ns To: Richard Guy Briggs Cc: 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, Dan Walsh , mpatel@redhat.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 Wed, Oct 30, 2019 at 6:04 PM Richard Guy Briggs wrote: > On 2019-10-30 16:27, Paul Moore wrote: > > On Thu, Oct 24, 2019 at 5:00 PM Richard Guy Briggs wrote: > > > Here's the note I had from that meeting: > > > > > > - Eric raised the issue that using /proc is likely to get more and more > > > hoary due to mount namespaces and suggested that we use a netlink > > > audit message (or a new syscall) to set the audit container identifier > > > and since the loginuid is a similar type of operation, that it should be > > > migrated over to a similar mechanism to get it away from /proc. Get > > > could be done with a netlink audit message that triggers an audit log > > > message to deliver the information. I'm reluctant to further pollute > > > the syscall space if we can find another method. The netlink audit > > > message makes sense since any audit-enabled service is likely to already > > > have an audit socket open. > > > > Thanks for the background info on the off-list meeting. I would > > encourage you to have discussions like this on-list in the future; if > > that isn't possible, hosting a public call would okay-ish, but a > > distant second. > > I'm still trying to get Eric's attention to get him to weigh in here and > provide a more eloquent representation of his ideas and concerns. Some > of it was related to CRIU(sp?) issues which we've already of which we've > already seen similar concerns in namespace identifiers including the > device identity to qualify it. Okay, let's leave this open until we hear from Eric to see if he has any additional information, but it's going to need to be pretty compelling. > > At this point in time I'm not overly concerned about /proc completely > > going away in namespaces/containers that are full featured enough to > > host a container orchestrator. If/when reliance on procfs becomes an > > issue, we can look at alternate APIs, but given the importance of > > /proc to userspace (including to audit) I suspect we are going to see > > it persist for some time. I would prefer to see you to drop the audit > > container ID netlink API portions of this patchset and focus on the > > procfs API. > > I've already refactored the code to put the netlink bits at the end as > completely optional pieces for completeness so they won't get in the way > of the real substance of this patchset. The nesting depth and total > number of containers checks have also been punted to the end of the > patchset to get them out of the way of discussion. That's fine, but if we do decide to drop the netlink API after hearing from Eric, please drop those from the patchset. Keeping the patchset small and focused should be a goal, and including rejected/dead patches (even at the end) doesn't help move towards that goal. > > Also, for the record, removing the audit loginuid from procfs is not > > something to take lightly, if at all; like it or not, it's part of the > > kernel API. > > Oh, I'm quite aware of how important this change is and it was discussed > with Steve Grubb who saw the concern and value of considering such a > disruptive change. Removing proc support for auid/ses would be a > long-term deprecation if accepted. As I mentioned, that comment was more "for the record" than you in particular; I know we've talked a lot over the years about kernel API stability and I'm confident you are aware of the pitfalls there. :) -- paul moore www.paul-moore.com