Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp638670imm; Mon, 21 May 2018 11:41:20 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrtsjA0HYI/pSHTU5Eky/6jXVebNft/V8n5ZERMKnkOGydC1LwFO5HQz9OezyZWJUyZ/ZaF X-Received: by 2002:a63:384d:: with SMTP id h13-v6mr16533627pgn.209.1526928080760; Mon, 21 May 2018 11:41:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526928080; cv=none; d=google.com; s=arc-20160816; b=c1WxF3xyJWwXSoUxc+N5xg/ylLAcGVmQ2k/Y8HEtJATPanvzGIWpA4ZfE7QlZN/o3S ngACRBFzlPyZi2NxV/XiEyXQoQsvd3P1dcw1I2QCayLCrD3u1OfQUjPKAQzIzDPow1kM dck/ag9keoBaie5ODNhxeel8ljvSZhlJX/of50rK6dJVnORaTnwSL8aKai/IPh6mTh7J E6IunXzE2sHBOk4G0aZe/uZPvhWkq6WqUgX4ZDkpchimbkrwSRScJuVRmVgB9sf4dtjh r+y+lOh5Q+t+tT8wAyzT5xKS3NtDW37GydBm3gYuXx+FZZjQuhpFO1rXzHTFylhO0eBj vEiA== 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:arc-authentication-results; bh=SdaTL0AICGZiEjs345O+hSl7Psom33hE7cDwIMklQBE=; b=mB4Qs3gvMRfBfTlpxFSq6pLcxganloU3qyJ3+jqBJbQ6QIdAZChHwEns6KgvmdJrqm 8l0dWzviuxZQrFUEItxEmPKW+iSnXRYi1y5tfxi4Pvn3SO6W++bAmF4KQyM0SsDh9IbJ 7dXl6Kb/g+eTE8unIRivH8i6nq2ymYSpgMVqWRSA3X+JT+pwEzEr6ruhR85VPMNh91Kr Cj8pm/o9kdPdSOMtAkrWjwnSNRbZnRT0Q607TxvdOM31sPlECUBGt835ZsVct1rAYBW2 0T+woVfyLAC9nJCpuDBhILyZDoE1LoeQ13Y9XmDZR2TFkZkAKar/2dqlMX6EcuMVCkPk +rFA== 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 m63-v6si13970122pld.429.2018.05.21.11.41.06; Mon, 21 May 2018 11:41:20 -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 S1751421AbeEUSkp (ORCPT + 99 others); Mon, 21 May 2018 14:40:45 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:38834 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750930AbeEUSkk (ORCPT ); Mon, 21 May 2018 14:40:40 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 507CB7D850; Mon, 21 May 2018 18:40:40 +0000 (UTC) Received: from x2.localnet (ovpn-122-110.rdu2.redhat.com [10.10.122.110]) by smtp.corp.redhat.com (Postfix) with ESMTP id DF10E2026DFD; Mon, 21 May 2018 18:40:39 +0000 (UTC) From: Steve Grubb To: Stefan Berger Cc: Mimi Zohar , Richard Guy Briggs , containers@lists.linux-foundation.org, Linux-Audit Mailing List , linux-integrity , LKML , paul@paul-moore.com Subject: Re: [PATCH] audit: add containerid support for IMA-audit Date: Mon, 21 May 2018 14:40:40 -0400 Message-ID: <16251997.Lr3lOVDqLJ@x2> Organization: Red Hat In-Reply-To: <7abd3460-0797-f003-12c7-7329beb0835b@linux.vnet.ibm.com> References: <1520257393.10396.291.camel@linux.vnet.ibm.com> <5705556.pzqfGOkdjC@x2> <7abd3460-0797-f003-12c7-7329beb0835b@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Mon, 21 May 2018 18:40:40 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Mon, 21 May 2018 18:40:40 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'sgrubb@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Stefan, On Monday, May 21, 2018 2:04:08 PM EDT Stefan Berger wrote: > On 05/21/2018 01:21 PM, Steve Grubb wrote: > > On Friday, May 18, 2018 12:34:24 PM EDT Mimi Zohar wrote: > >> On Fri, 2018-05-18 at 11:56 -0400, Richard Guy Briggs wrote: > >>> On 2018-05-18 10:39, Mimi Zohar wrote: > >>>> On Fri, 2018-05-18 at 09:54 -0400, Stefan Berger wrote: > >>>>> On 05/18/2018 08:53 AM, Mimi Zohar wrote: > >>>> [..] > >>>> > >>>>>>>>> If so, which ones? We could probably refactor the current > >>>>>>>>> integrity_audit_message() and have ima_parse_rule() call into it > >>>>>>>>> to get those fields as well. I suppose adding new fields to it > >>>>>>>>> wouldn't be considered breaking user space? > >>>>>>>> > >>>>>>>> Changing the order of existing fields or inserting fields could > >>>>>>>> break stuff and is strongly discouraged without a good reason, but > >>>>>>>> appending fields is usually the right way to add information. > >>>>>>>> > >>>>>>>> There are exceptions, and in this case, I'd pick the "more > >>>>>>>> standard" of the formats for AUDIT_INTEGRITY_RULE > >>>>>>>> (ima_audit_measurement?) and stick with that, abandoning the other > >>>>>>>> format, renaming the less standard version of the record > >>>>>>>> (ima_parse_rule?) and perhpas adopting that abandonned format for > >>>>>>>> the new record type while using current->audit_context. > >>>>>> > >>>>>> This sounds right, other than "type=INTEGRITY_RULE" (1805) for > >>>>>> ima_audit_measurement(). Could we rename type=1805 to be > >>>>> > >>>>> So do we want to change both? I thought that what > >>>>> ima_audit_measurement() produces looks ok but may not have a good > >>>>> name for the 'type'. Now in this case I would not want to 'break user > >>>>> space'. The only change I was going to make was to what > >>>>> ima_parse_rule() produces. > >>>> > >>>> The only change for now is separating the IMA policy rules from the > >>>> IMA-audit messages. > >>>> > >>>> Richard, when the containerid is appended to the IMA-audit messages, > >>>> would we make the audit type name change then? > >>> > >>> No, go ahead and make the change now. I'm expecting that the > >>> containerid record will just be another auxiliary record and should not > >>> affect you folks. > >> > >> To summarize, we need to disambiguate the 1805, as both > >> ima_parse_rule() and ima_audit_measurement() are using the same number > >> with different formats. The main usage of 1805 that we are aware of > >> is ima_audit_measurement(). Yet the "type=" name for > >> ima_audit_measurement() should be INTEGRITY_IMA_AUDIT, not > >> INTEGRITY_RULE. > >> > >> option 1: breaks both uses > >> 1805 - INTEGRITY_IMA_AUDIT - ima_audit_measurement() > >> 1806 - INTEGRITY_POLICY_RULE - ima_parse_rule() > >> > >> option 2: breaks the most common usage > >> 1805 - INTEGRITY_RULE - ima_parse_rule() > >> 1806 - INTEGRITY_IMA_AUDIT - ima_audit_measurement() > >> > >> option 3: leaves the most common usage with the wrong name, and breaks > >> the other less common usage > >> 1805 - INTEGRITY_RULE - ima_audit_measurement() > >> 1806 - INTEGRITY_POLICY_RULE - ima_parse_rule() > >> > >> So option 3 is the best option? > >> > > From a user space perspective, I don't care as long the event is well > > formed > > Are you saying this because of the tools you referred to that require > proper ordering and all fields need to be available? Its because the order was established a long time ago. User space tools still expect that ordering. > > (No unnecessary untrusted string logging) and we have the required fields > > for searching: pid, uid, auid, tty, session, subj, comm, exe, & res. And > > the object is identifiable in the event. > > There's at least one documented user that showed the existing format... > > https://www.fireeye.com/blog/threat-research/2016/11/extending_linux_exec.h > tml Hmm. I see. If that event was ever sent to linux-audit mail list for feedback, we would have had some discussion because it's not a proper event. The order of the fields changed, new fields were added, untrusted string logging is being used, field names are not documented in the field name dictionary, existing field names are not being used, subject information is incomplete, results is missing, and its not entirely clear what the object is. -Steve