From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761803AbdJQMbW (ORCPT ); Tue, 17 Oct 2017 08:31:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5208 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753116AbdJQMbT (ORCPT ); Tue, 17 Oct 2017 08:31:19 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 694687E428 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=simo@redhat.com Message-ID: <1508243469.6230.24.camel@redhat.com> Subject: Re: RFC(v2): Audit Kernel Container IDs From: Simo Sorce To: Steve Grubb , linux-audit@redhat.com Cc: Richard Guy Briggs , Casey Schaufler , mszeredi@redhat.com, "Eric W. Biederman" , 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 Date: Tue, 17 Oct 2017 08:31:09 -0400 In-Reply-To: <2319693.5l3M4ZINGd@x2> References: <20171012141359.saqdtnodwmbz33b2@madcap2.tricolour.ca> <75b7d6a6-42ba-2dff-1836-1091c7c024e7@schaufler-ca.com> <20171017003340.whjdkqmkw4lydwy7@madcap2.tricolour.ca> <2319693.5l3M4ZINGd@x2> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 17 Oct 2017 12:31:19 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2017-10-16 at 21:42 -0400, Steve Grubb wrote: > On Monday, October 16, 2017 8:33:40 PM EDT Richard Guy Briggs wrote: > > 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 difference is that with loginuid you needed to give processes able to audit also the ability to change it. You do not want to tie the ability to change container ids to the ability to audit. You want to be able to do audit stuff (within the container) without allowing it to change the container id. Of course if we made container id a write-once property maybe there is no need for controls at all, but I'm pretty sure there will be situations where write-once may not be usable in practice. > The ability to arbitrarily set a container ID means the process has > the ability to indirectly control the audit trail. The container Id can be used also for authorization purposes (by other processes on the host), not just audit, I think this is why a separate control has been proposed. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc