Received: by 10.192.165.156 with SMTP id m28csp82596imm; Wed, 18 Apr 2018 17:48:10 -0700 (PDT) X-Google-Smtp-Source: AIpwx48i69G+iaSnynVv+5Y7c/H8Y532z7eWJMqj5njB/HtVSLmkYlDTyOIeXsmX/7jKStkZDM/i X-Received: by 10.99.98.66 with SMTP id w63mr3277880pgb.377.1524098890243; Wed, 18 Apr 2018 17:48:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524098890; cv=none; d=google.com; s=arc-20160816; b=a+JMKnCFGKIxoWaP1hUQisAgsY3oXPhoSf+Ev9vkpNsm/KAODpo2EYYxe3kwtUGe1z G0hZH6Im4pymowghllYFT8qDJWVQcfaj+IHaCT6JM9n0m1v1nmHAwvV8VtE9yuoTB3U2 klXS9FVVEn+HEQ/mwSDKRQX7dW3tSN50xm79woq7Mo126BsmwkR0XJsmvG9kbfF2q7kQ Z95Al+BMaIakHV8dp+fL8FryEOCH1AKBo84aqRl4ZKUB7jBSt3PgUb6AVR7HHIu8ifie R8HdAs8NwM/QRwZDkHBsi2HbFtOt0WZVMjkwV8mXCpkEJ2rzAJs34mZ2/xAH5uccAfK0 GurA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=4BxKZDOGo3vKJKh5O3e2GiQOfk9s4iU3K6GjiiTTp9w=; b=QQ2mApOKyS9wgAs8xucZK2XN7QVZBUPMzXIn5vcBgr4KsCbluCn/xk2bkyWkDHnaFI sigePgP4OpA5yK7/Y5EFakq6/lpdOm4Mn9XEMgKsJxp3zNgwVYPAxErQWC/VUc8UZ6Td d7Q5kVoKXFgSp3f73lA5wLBnMadT7tz7BSGQPfLs+KN/dy5TNDlKg2ewu8Cpob1TzL6J L0Khfn9ySzPK+eL/uJdX2HSrE0WdBY8czNcT/ifqdT+RPyVoJpn7okalJWTIleyiiVdU vNLoZoPAGW/SvlzVPWPsMPt6NJ2aLkcMsVC89wj+xhDxOP3VWIBVE8aKygAWxk8YmOZ2 fg1A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=uTG6NZf5; 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 s10si1961797pgq.162.2018.04.18.17.47.56; Wed, 18 Apr 2018 17:48:10 -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=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=uTG6NZf5; 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 S1753277AbeDSAqu (ORCPT + 99 others); Wed, 18 Apr 2018 20:46:50 -0400 Received: from mail-lf0-f68.google.com ([209.85.215.68]:35326 "EHLO mail-lf0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753098AbeDSAqr (ORCPT ); Wed, 18 Apr 2018 20:46:47 -0400 Received: by mail-lf0-f68.google.com with SMTP id r125-v6so5241463lfe.2 for ; Wed, 18 Apr 2018 17:46:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4BxKZDOGo3vKJKh5O3e2GiQOfk9s4iU3K6GjiiTTp9w=; b=uTG6NZf5G9dczgI8zvrsxrHPaJB2N8UTl+Ihd8LL4mRonWZlPJHr/dbM7fVA//vNg0 m4qp+7NbCWwYu86v3TL8QzWkt4mmaS+DF4zl85jAs7g+/YVMBpGpzLfb93HnquiybTJz +ZPdTBBGidqVIjuy9HjyH9aAVpaPGSxbOEYpz4Ovek54JQ+P4FIKjzcNqPDf6UCQcjtO QdXqv4xeB68Th0Gg8WlCTlCayOTBlqb6nhyoPINgtN0FjlgSUzjQWZxbqCLtRbQTUHWd 3jRK7A/qmT5mshvD8q+/XkEzCc1hOHBjn9KrafiEL+HPQQNh/fUearuBf7fjMKSBvglk iZqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4BxKZDOGo3vKJKh5O3e2GiQOfk9s4iU3K6GjiiTTp9w=; b=JmD3PidCkpj8EObv2G3FDvQje2Zhp5WmuQ080SfSPAoosNCoKP9oEK6FY15Zl5gMD5 2v/mhCariCcCLwDqXlE7l7Yaa/ul6pHb6aHxcWaACT0z/DKXRHzzEZZg4C75HSttO+9o iiHr/LeF3yhNkTH729oYOY8TOLcHJJ7qrZe4TC8kbmG3gXmgWyl+vTrhX8CLarNriUhr aqHl3YuOyZBJnM2DxbmH+crLxxaFZxutPwZDcIDzWUmVUeREzodEAQHUsbJKWkdb37Gz 66fgAke9/CFktMIyMgUljf3DV0NTFrXs+EnnONYTfFO77DjShO7LIfNXqRV90NiAZF1b VHKw== X-Gm-Message-State: ALQs6tDGsBvx778oTsx6RRBWEoherYXlqMkvisUJ9W3VhuzNj8BURKFq U+AbUsWOhMrKhqAuGavY1NduGoiZQfnk3joTrvIi X-Received: by 2002:a19:1895:: with SMTP id 21-v6mr2681667lfy.39.1524098806427; Wed, 18 Apr 2018 17:46:46 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:a5c3:0:0:0:0:0 with HTTP; Wed, 18 Apr 2018 17:46:45 -0700 (PDT) X-Originating-IP: [108.20.156.165] In-Reply-To: <32d3e7a6-36f0-571a-bb91-67f746c7eafa@schaufler-ca.com> References: <32d3e7a6-36f0-571a-bb91-67f746c7eafa@schaufler-ca.com> From: Paul Moore Date: Wed, 18 Apr 2018 20:46:45 -0400 Message-ID: Subject: Re: [RFC PATCH ghak32 V2 01/13] audit: add container id To: Casey Schaufler 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Further, I don't want to entangle two very complicated code changes or make the audit container ID effort dependent on LSM stacking. You're a good salesman Casey, but you're not that good ;) -- paul moore www.paul-moore.com