From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751480AbdJSXPj (ORCPT ); Thu, 19 Oct 2017 19:15:39 -0400 Received: from mx2.suse.de ([195.135.220.15]:41674 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751244AbdJSXPh (ORCPT ); Thu, 19 Oct 2017 19:15:37 -0400 Subject: Re: RFC(v2): Audit Kernel Container IDs From: Aleksa Sarai To: Richard Guy Briggs , Steve Grubb Cc: cgroups@vger.kernel.org, mszeredi@redhat.com, David Howells , Simo Sorce , jlayton@redhat.com, "Carlos O'Donell" , Linux API , Linux Containers , Linux Kernel , Paul Moore , Linux Audit , Al Viro , Andy Lutomirski , Eric Paris , Linux FS Devel , trondmy@primarydata.com, Linux Network Development , "Eric W. Biederman" References: <20171012141359.saqdtnodwmbz33b2@madcap2.tricolour.ca> <2307769.VGpzlLa4Dp@x2> <20171019195747.4ssujtaj3f5ipsoh@madcap2.tricolour.ca> <8f495870-dd6c-23b9-b82b-4228a441c729@suse.de> Message-ID: Date: Fri, 20 Oct 2017 10:15:25 +1100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <8f495870-dd6c-23b9-b82b-4228a441c729@suse.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >>>> 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. >>> >>> Wouldn't CAP_AUDIT_WRITE be sufficient? After all, this is for auditing. >> >> No, because then any process with that capability (vsftpd) could change >> its own container ID.  This is discussed more in other parts of the >> thread... > > Not if we make the container ID append-only (to support nesting), or > write-once (the other idea thrown around). In that case, you can't move > "out" from a particular container ID, you can only go "deeper". These > semantics don't make sense for generic containers, but since the point > of this facility is *specifically* for audit I imagine that not being > able to move a process from a sub-container's ID is a benefit. [This assumes it's CAP_AUDIT_CONTROL which is what we are discussing in a sister thread.] -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/