Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp4792928ybg; Mon, 21 Oct 2019 14:40:00 -0700 (PDT) X-Google-Smtp-Source: APXvYqz94HHuxa08d1EpGJSLS0GjZ0oF5gVMDrNqZNIjBtIfo4QUSbo5xnNaYWZ/t8/T3TU0N2u7 X-Received: by 2002:a50:8dc5:: with SMTP id s5mr27310461edh.115.1571693999962; Mon, 21 Oct 2019 14:39:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571693999; cv=none; d=google.com; s=arc-20160816; b=HM3eAawjnmLZ9JeUSxzZstKbNxLWB5rnJ2AvGfKSOUWltVHCA9WfF+VrEOuvl80yVE pMsgoauK3yMwAvHpZlnABWmMC1GC0Ms8SmgHHGYkr6Ix4UkaRBOUEcnH/bNdzuNxkPiy BNMDv+qzCP92U3Hyq1EZv/EZu+4QXiJ6HP8xJIryOZdNIwrjctE+34BpCI5ObPxLGpaL ha6Hk1Fy6akDwLiFmk36nFwNguADBp68rkix69OLPQrPjkP025KpR6NnO6YEUQhtL+nN /3HmTz/I5PDpr1MQtwUEWSDBnE4XV1GlwoUcdH5ttOI0Zueel6dOYM5DuxNKPGuqIXEO FJbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-disposition :content-transfer-encoding:user-agent:in-reply-to:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=0ydo/TL5LDscvwdIxWlFvz3d4kbBSbMTez/KsfHBMEM=; b=ipnwhWlMKKoBlGlgG/5owWXzwHmK4xg48+ffycdd/IB81ZoCzvXS/13XcbZWlKPN+G 7NZwDlc8u2s2rgPvDqglwpEQrqbCMAIErlKmULaKODEcAHcidMF8l/UN+UVImLbNuzq5 BpX9EhpT8jDq4PoVCk+WSgKKiQMcmFdnId11qW27A9/ywOWEDOYt5rC46Nvv5ssUzcel XtrtzLdX/Bvsz2J498QypQERuhxIOk3mwOphixjOsATZogXAbS8R4eQR9neTsh1gu79B fubNpMVQJAuruoJkcYdOC+2llecmqqAxkgbHv757I8EiQd/KGX16RsHuwVOfKNHhX84R 6nqw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=aW5eOUlp; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y54si1501884edb.136.2019.10.21.14.39.34; Mon, 21 Oct 2019 14:39:59 -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=@redhat.com header.s=mimecast20190719 header.b=aW5eOUlp; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730283AbfJUViy (ORCPT + 99 others); Mon, 21 Oct 2019 17:38:54 -0400 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:36590 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730052AbfJUViy (ORCPT ); Mon, 21 Oct 2019 17:38:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1571693932; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0ydo/TL5LDscvwdIxWlFvz3d4kbBSbMTez/KsfHBMEM=; b=aW5eOUlpsUnlhg9LVoJ/+KqAWiJqJJ0rVV6jwt2GiW1hCAwVWjUf/tB/VSbSteyLZKNeGv XmVBldIXztH0/acGET+J7lY4Vmz+5k9KUtq/iStCaNNQUec493rWmVliWRgRZusCYnUZpV 0Y4sa4imLjm76BYj9AsSB4X4x1sWPNg= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-297-2lBc4Mw4NFGMJ83795y3WA-1; Mon, 21 Oct 2019 17:38:49 -0400 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D3658800D41; Mon, 21 Oct 2019 21:38:45 +0000 (UTC) Received: from madcap2.tricolour.ca (ovpn-112-19.phx2.redhat.com [10.3.112.19]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B2D4E1001B20; Mon, 21 Oct 2019 21:38:27 +0000 (UTC) Date: Mon, 21 Oct 2019 17:38:24 -0400 From: Richard Guy Briggs To: Paul Moore 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 Subject: Re: [PATCH ghak90 V7 20/21] audit: add capcontid to set contid outside init_user_ns Message-ID: <20191021213824.6zti5ndxu7sqs772@madcap2.tricolour.ca> References: <214163d11a75126f610bcedfad67a4d89575dc77.1568834525.git.rgb@redhat.com> <20191019013904.uevmrzbmztsbhpnh@madcap2.tricolour.ca> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-MC-Unique: 2lBc4Mw4NFGMJ83795y3WA-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019-10-21 15:53, Paul Moore wrote: > On Fri, Oct 18, 2019 at 9:39 PM Richard Guy Briggs wrote= : > > On 2019-09-18 21:22, Richard Guy Briggs wrote: > > > Provide a mechanism similar to CAP_AUDIT_CONTROL to explicitly give a > > > process in a non-init user namespace the capability to set audit > > > container identifiers. > > > > > > Use audit netlink message types AUDIT_GET_CAPCONTID 1027 and > > > AUDIT_SET_CAPCONTID 1028. The message format includes the data > > > structure: > > > struct audit_capcontid_status { > > > pid_t pid; > > > u32 enable; > > > }; > > > > Paul, can I get a review of the general idea here to see if you're ok > > with this way of effectively extending CAP_AUDIT_CONTROL for the sake o= f > > setting contid from beyond the init user namespace where capable() can'= t > > reach and ns_capable() is meaningless for these purposes? >=20 > I think my previous comment about having both the procfs and netlink > interfaces apply here. I don't see why we need two different APIs at > the start; explain to me why procfs isn't sufficient. If the argument > is simply the desire to avoid mounting procfs in the container, how > many container orchestrators can function today without a valid /proc? Ok, sorry, I meant to address that question from a previous patch comment at the same time. It was raised by Eric Biederman that the proc filesystem interface for audit had its limitations and he had suggested an audit netlink interface made more sense. The intent was to switch to the audit netlink interface for contid, capcontid and to add the audit netlink interface for loginuid and sessionid while deprecating the proc interface for loginuid and sessionid. This was alluded to in the cover letter, but not very clear, I'm afraid. I have patches to remove the contid and loginuid/sessionid interfaces in another tree which is why I had forgotten to outline that plan more explicitly in the cover letter. > paul moore - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635