Received: by 10.192.165.156 with SMTP id m28csp107637imm; Wed, 18 Apr 2018 18:17:23 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/8CyvYtCU4PE57Q6YyEf0F6nIJjK3z2C659XV615WeyOnvW2FAXnBe/+N/uGJ6ey1V342C X-Received: by 2002:a17:902:51ce:: with SMTP id y72-v6mr4031741plh.157.1524100643010; Wed, 18 Apr 2018 18:17:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524100642; cv=none; d=google.com; s=arc-20160816; b=UHj8DmAihSv++B+ueDpscceSUgx5/0r45H93I0xAL6Vh6CjBJ95waWeizXrvEHil1+ jnduKwodGMg+fxG8HHt2BzplvGF2nFmkLQ8RGdP8o7ziol1HJ5nzxi7XDt+mlE091tK3 qQzoeCmanmD/YFFYIfc4IqwRlEZtvmHImEZKvR73oRmnrFdalneWtZmUFAHeKj2DFYyN Z8K1fkMMXCyCF6CzuBeH11rvdo1zIosgRhpSRn0n+6n6RLee6ju6gWEUakn1AH/tyzjQ YECfEAcVIWEWtoEDXIXNrJb2wCX9+mXlByVR7k0o9GL6X47TRQYPjd/5LwMVciRcy22C WX1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=LKvFpOVyFRXBviGQwQCf2C0uj1Y10oHufwGPGfzSn9U=; b=HupjcPB3jGDgbUgS7+YG7TM8DOYaTeMZPtcWRW9rIWTbcID2IGxhbIkXUcGZiuPqFv Z2q3ooJntNDeLscRqMLI+MQqTY4AzMlj1X0rP/B3D4p0asAY2Paaz9k+qqbeHDCK5q/M 30d/RInjvFWj6tiIUcoialWGFA3SrANnTcJMmll08fWr5se6DJRpVzKEdMCLO8As8My8 mcnLv8NLhSqaFKaeVGk537TcUHoCH8acKDfv4qO+ywrpQJF5FYtVBczw8irxR0hYFcbZ FFj064YtLzoHNAH/d0gSS8T5j3HnMLRqq4O7CLAaRjrlmiBkZuBHBCF4eAImgLvTTfu0 gy6g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@yahoo.com header.s=s2048 header.b=PLazFpB9; 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 u9si1989524pge.641.2018.04.18.18.17.08; Wed, 18 Apr 2018 18:17:22 -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=@yahoo.com header.s=s2048 header.b=PLazFpB9; 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 S1752634AbeDSBP7 (ORCPT + 99 others); Wed, 18 Apr 2018 21:15:59 -0400 Received: from sonic316-20.consmr.mail.bf2.yahoo.com ([74.6.130.194]:43667 "EHLO sonic316-20.consmr.mail.bf2.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752116AbeDSBP5 (ORCPT ); Wed, 18 Apr 2018 21:15:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1524100556; bh=LKvFpOVyFRXBviGQwQCf2C0uj1Y10oHufwGPGfzSn9U=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=PLazFpB9Hcj92rBPwaxDuljfxgFBilIkSRlJtDBENHrJYDcj8QTPeDlz3hjru3iaOpSCCviXkbg8tFoFaobHfExvswvh6WXa5u6HvmuCoruUQla3j67bFwXS9U8AvEAtZ9dd54yf5TopfPxuDrIaAp0hK0ju+E8bDwIXAuRPEWEm2AzM60bOo7H4eHEuZVh7dqg8QYTxpfoj53g37DrQ+WFUy9Rhgy9BnAytWzHZF0m/H/VJuIF7+P49cAjUSUS4GP9v3apWk1oc0JJaqWjtLvP/mSrxAMPww5jXbsKKdGZ44v784YL/TCYGXNFD8/Nv2NnSiUwgPHpZkEuGfh9G2g== X-YMail-OSG: 6ETDIScVM1ngf1IZvXwAtgJzQf3EaZScWdTJ3y9dzUpW7u3iFXGKYLj96v7W8.U _l8R9HTkwUwcQCBvSsmR4Aj9YuvZQ9idZBrfU6WmCFwJWHXrt3aSVqampSfcwFZR5V678QMqn8w4 gztM39f33TfQIt1nVV5QsdLe1qwshjrxZlTToqlHRTJHKE.swX0pB9fBQc6qoFvXWAd2Wjf_l0LB N.WtZQb0OkJG12xgjk_9QymAMzREFD8pG7wqRBdee4tA3us.MAGmmr46SmYqqRsdZXRBbtTPeLob 4dXB.EvZDYVA0D2dw87ROb1coH2DqDFgiPAdbTzGyvYRlO2VXCDZOO9XffcU80d4NqxnUvnSd3Ax 4GpSWYRIkoN.ZTMyuL0VmHwMW1XMdPgmn4MC4m3f2.hcNy4qJ1.NWe3rTs2Evga8S08ZWwuez2rX ge.48rT_Q7txMtoL1x.dwdU1CHnRVmrT8AWsS_mPs8gDqtE6Kesem5DMHTO6iDzPE_PWqkH1Gwqi UtJl5gMRCmXS4mG8Y8o0riNhoyssuRhaDXQuqz2E9B4W082W0yleUHA8v7xdJaknJMTsAjCb1SB0 jxN.kHK2HZjjpRTFgZToW Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Thu, 19 Apr 2018 01:15:56 +0000 Received: from c-67-169-65-224.hsd1.ca.comcast.net (EHLO [192.168.0.105]) ([67.169.65.224]) by smtp401.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 5172f6eeeec91c20b063e8ce9b09dcc0; Thu, 19 Apr 2018 01:15:52 +0000 (UTC) Subject: Re: [RFC PATCH ghak32 V2 01/13] audit: add container id To: Paul Moore Cc: Richard Guy Briggs , cgroups@vger.kernel.org, containers@lists.linux-foundation.org, linux-api@vger.kernel.org, Linux-Audit Mailing List , linux-fsdevel@vger.kernel.org, LKML , netdev@vger.kernel.org, ebiederm@xmission.com, luto@kernel.org, jlayton@redhat.com, carlos@redhat.com, dhowells@redhat.com, viro@zeniv.linux.org.uk, simo@redhat.com, Eric Paris , serge@hallyn.com References: <32d3e7a6-36f0-571a-bb91-67f746c7eafa@schaufler-ca.com> From: Casey Schaufler Message-ID: <1adffa90-020d-54e1-fbf5-7fc929ccb44c@schaufler-ca.com> Date: Wed, 18 Apr 2018 18:15:46 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/18/2018 5:46 PM, Paul Moore wrote: > On Wed, Apr 18, 2018 at 8:41 PM, Casey Schaufler wrote: >> On 4/18/2018 4:47 PM, Paul Moore wrote: >>> On Fri, Mar 16, 2018 at 5:00 AM, Richard Guy Briggs wrote: >>>> Implement the proc fs write to set the audit container ID of a process, >>>> emitting an AUDIT_CONTAINER record to document the event. >>>> ... >>>> >>>> diff --git a/include/linux/sched.h b/include/linux/sched.h >>>> index d258826..1b82191 100644 >>>> --- a/include/linux/sched.h >>>> +++ b/include/linux/sched.h >>>> @@ -796,6 +796,7 @@ struct task_struct { >>>> #ifdef CONFIG_AUDITSYSCALL >>>> kuid_t loginuid; >>>> unsigned int sessionid; >>>> + u64 containerid; >>> This one line addition to the task_struct scares me the most of >>> anything in this patchset. Why? It's a field named "containerid" in >>> a perhaps one of the most widely used core kernel structures; the >>> possibilities for abuse are endless, and it's foolish to think we >>> would ever be able to adequately police this. >> If we can get the LSM infrastructure managed task blobs from >> module stacking in ahead of this we could create a trivial security >> module to manage this. It's not as if there aren't all sorts of >> interactions between security modules and the audit system already. > While yes, there are plenty of interactions between the two, it is > possible to use audit without the LSMs and I would like to preserve > that. Fair enough. > Further, I don't want to entangle two very complicated code > changes or make the audit container ID effort dependent on LSM > stacking. Also fair, although the use case for container audit IDs is already pulling in audit, namespaces (yeah, I know it's not necessary for a container to use namespaces) security modules (stacked and/or namespaced), cgroups and who knows what else. > You're a good salesman Casey, but you're not that good ;) I have to keep the skills sharpened somehow! OK, I'll grant that this isn't a great fit.