Received: by 10.223.164.221 with SMTP id h29csp1439963wrb; Tue, 17 Oct 2017 03:18:50 -0700 (PDT) X-Google-Smtp-Source: AOwi7QAC+IAPG35uFNVi7R/f+4XDAdIht/2zbfMU0q050awO4uQQxRsyMwy4BwjJx7kmZ//yJ2wv X-Received: by 10.99.109.75 with SMTP id i72mr10614215pgc.268.1508235530485; Tue, 17 Oct 2017 03:18:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1508235530; cv=none; d=google.com; s=arc-20160816; b=loUJdT7WJXfZymQ22b6H8NPkqzCf+OVdY/nFNL2FdSU3W6dwQBAeEWUVIFBai2eBR4 2xFXf+mMjY4VUhxIXUvrli+LLP2jesHUVHCrVey5UH6quGUNv/buXi7fvQNukZIQ8mng VQOM94hvDhVPJKcaIEIIi+dMg79Alvh+Q/3a59SS3tpDD6Z+5vf3C8T5b9vVLnyXIeMm IAITA0PlSP2/r5PUeXVfOnCf4+t9XJw7Wre0P+qCfuJUICd56uoi538gCDWH7Yjl+rr1 jaG1Wb8QCibdG2Rl9Xg0E1DLst6saSlPxnm2Qnl0JdgAbwcDnUaEY/RWA1zrYdlSf8la gMpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:organization:message-id:date:subject:cc:to :from:dmarc-filter:arc-authentication-results; bh=oylEHbX7Ehymr+yxO6TAktGFswnsmQf2kS8HD4nCewE=; b=kGf2o1MoRgsiFfW2dV4yeZt7oZWigtUPCjOLU4vSjxxCHS/4pRwqd9+rmjQWz1om+K IewP8uoXWNYHx53mPZ7vbrNWLX3ZCbnFgcYObfq/iFes48Cg63V2ppk0YUvp1L5lXa/7 /sLbHznVjaHhXqEcXibtDVCB5lZ6R8YNlfDLAN5Pfzk2iMo3weGBTKaWnPmX3XN9z/VD ZfrngOitMjovigWzBPmUR9L0acR2tHQ5l8Pk7+wzzQnwwZ0svemATjlEuIDYGLWnme9k 4wMkTo8DZscYVnf9G9A23Wn3kqUKp3xmxrZMX19oSshYOUCZjdF71pLPfJtqvZI1iSqN 1kOQ== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (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 d11si720974pgu.356.2017.10.17.03.18.36; Tue, 17 Oct 2017 03:18:50 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758104AbdJQBnK (ORCPT + 99 others); Mon, 16 Oct 2017 21:43:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34924 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756661AbdJQBnH (ORCPT ); Mon, 16 Oct 2017 21:43:07 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3BBA5356E6; Tue, 17 Oct 2017 01:43:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 3BBA5356E6 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=sgrubb@redhat.com Received: from x2.localnet (ovpn-120-212.rdu2.redhat.com [10.10.120.212]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9B93560852; Tue, 17 Oct 2017 01:42:56 +0000 (UTC) From: Steve Grubb To: linux-audit@redhat.com Cc: Richard Guy Briggs , Casey Schaufler , mszeredi@redhat.com, "Eric W. Biederman" , Simo Sorce , jlayton@redhat.com, Carlos O'Donell , Linux API , Linux Containers , Linux Kernel , Eric Paris , David Howells , Al Viro , Andy Lutomirski , Linux Network Development , Linux FS Devel , cgroups@vger.kernel.org, "Serge E. Hallyn" , trondmy@primarydata.com Subject: Re: RFC(v2): Audit Kernel Container IDs Date: Mon, 16 Oct 2017 21:42:52 -0400 Message-ID: <2319693.5l3M4ZINGd@x2> Organization: Red Hat In-Reply-To: <20171017003340.whjdkqmkw4lydwy7@madcap2.tricolour.ca> References: <20171012141359.saqdtnodwmbz33b2@madcap2.tricolour.ca> <75b7d6a6-42ba-2dff-1836-1091c7c024e7@schaufler-ca.com> <20171017003340.whjdkqmkw4lydwy7@madcap2.tricolour.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Tue, 17 Oct 2017 01:43:06 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday, October 16, 2017 8:33:40 PM EDT Richard Guy Briggs wrote: > On 2017-10-12 16:33, Casey Schaufler wrote: > > On 10/12/2017 7:14 AM, Richard Guy Briggs wrote: > > > Containers are a userspace concept. The kernel knows nothing of them. > > > > > > The Linux audit system needs a way to be able to track the container > > > provenance of events and actions. Audit needs the kernel's help to do > > > this. > > > > > > Since the concept of a container is entirely a userspace concept, a > > > registration from the userspace container orchestration system initiates > > > this. This will define a point in time and a set of resources > > > associated with a particular container with an audit container ID. > > > > > > The registration is a pseudo filesystem (proc, since PID tree already > > > exists) write of a u8[16] UUID representing the container ID to a file > > > representing a process that will become the first process in a new > > > container. This write might place restrictions on mount namespaces > > > required to define a container, or at least careful checking of > > > namespaces in the kernel to verify permissions of the orchestrator so it > > > can't change its own container ID. A bind mount of nsfs may be > > > necessary in the container orchestrator's mntNS. > > > Note: Use a 128-bit scalar rather than a string to make compares faster > > > and simpler. > > > > > > Require a new CAP_CONTAINER_ADMIN to be able to carry out the > > > registration. > > > > Hang on. If containers are a user space concept, how can > > you want CAP_CONTAINER_ANYTHING? If there's not such thing as > > a container, how can you be asking for a capability to manage > > them? > > There is such a thing, but the kernel doesn't know about it yet. This > same situation exists for loginuid and sessionid which are userspace > concepts that the kernel tracks for the convenience of userspace. As > for its name, I'm not particularly picky, so if you don't like > CAP_CONTAINER_* then I'm fine with CAP_AUDIT_CONTAINERID. It really > needs to be distinct from CAP_AUDIT_WRITE and CAP_AUDIT_CONTROL since we > don't want to give the ability to set a containerID to any process that > is able to do audit logging (such as vsftpd) and similarly we don't want > to give the orchestrator the ability to control the setup of the audit > daemon. A long time ago, we were debating what should guard against rouge processes from setting the loginuid. Casey argued that the ability to set the loginuid means they have the ability to control the audit trail. That means that it should be guarded by CAP_AUDIT_CONTROL. I think the same logic applies today. The ability to arbitrarily set a container ID means the process has the ability to indirectly control the audit trail. -Steve From 1581499294223459862@xxx Tue Oct 17 10:14:18 +0000 2017 X-GM-THRID: 1581061469540113612 X-Gmail-Labels: Inbox,Category Forums