Received: by 2002:a05:6a10:6006:0:0:0:0 with SMTP id w6csp477085pxa; Thu, 27 Aug 2020 07:29:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxXMPTCaDcRnRMou2KpvD2Cdb5BKW5DYCOpS2eNjhk78jz9iyhdSWc+s4g9y6lF9ERl2ro7 X-Received: by 2002:a17:906:d84:: with SMTP id m4mr22219602eji.205.1598538544530; Thu, 27 Aug 2020 07:29:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598538544; cv=none; d=google.com; s=arc-20160816; b=KGMna7R41IHHCzi6cBmzogJQMM88QJkfGBcQB3vqCt0VzXV8cmdKiavZ6l64VrCWTG NMOKLcWio0IKCxfnceDlEfZ8YAfipS8V4FJ/2prUsypjCwgnOwp9SrNXOqsYq2fzOuiv /sk9mrpW6LA98HDKV4YDEFpvk2jbkuM3O67JHjrDXbeths6b3wrfrxHaw9nN4yr2d9XT xIXTVJBKkLQAFm0Pv0zTSTmjTxgoxwFQ80sjMUNqpgpJ45+RSTLnkh5tHF5iIdUo0vsf iSaOq8hFIbUfN/jxYUZjpc8nwi3lboK1astcKi+RioA93fve1FnB0QfhZa4r2DfsHddi oG7w== 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; bh=Bpu/wlLETYAMfn+axV25cy+odgitb8g2AwO8mC573xY=; b=sHBIx1ovLVwR6PGlEl0DyN8l86ckR457LJLr3FQ8Vwe/i+7qSh6lnggBYlDl6aFFYW 37B9DWeryVAiuovzgB+j7/X2hZULq8NsYL+GinW4qGO0oClZUBYjH/ZRObM0TqW29Op4 ssWu1Pcajr/XPscmvr8KPxNeJbhHav+AUZGf9EPSv7qUsRCazOXbSuk5QxwtVkwbUzrX /V0OADihqYw/ADf9OGR2i4juS5fpVWG52JhHOzfVkAQUOG3QsdttZhg/bAzydZsgVCJM qzlBJBShyrm63d7W6IJI2hiMh554o1z8N/36WtvyxOU7vtoFyrgfkrlyGgIdGTj/Wsi+ JZLA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=sony.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 12si1541286edv.587.2020.08.27.07.28.41; Thu, 27 Aug 2020 07:29:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=sony.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728072AbgH0O1P convert rfc822-to-8bit (ORCPT + 99 others); Thu, 27 Aug 2020 10:27:15 -0400 Received: from jptosegrel01.sonyericsson.com ([124.215.201.71]:18340 "EHLO JPTOSEGREL01.sonyericsson.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727103AbgH0OQm (ORCPT ); Thu, 27 Aug 2020 10:16:42 -0400 X-Greylist: delayed 672 seconds by postgrey-1.27 at vger.kernel.org; Thu, 27 Aug 2020 10:16:39 EDT Subject: Re: [RFC PATCH] selinux: Add denied trace with permssion filter To: Paul Moore CC: , SElinux list , Steven Rostedt , Stephen Smalley References: <20200824132252.31261-1-peter.enderborg@sony.com> <20200824132252.31261-2-peter.enderborg@sony.com> <6cbe5d27-ebb2-70a6-bad4-31c9f310eff2@sony.com> <59fa190f-37c0-79f3-ea46-8f821d820e1c@sony.com> From: peter enderborg Message-ID: Date: Thu, 27 Aug 2020 16:04:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT Content-Language: en-GB X-SEG-SpamProfiler-Analysis: v=2.3 cv=FfdJO626 c=1 sm=1 tr=0 a=9drRLWArJOlETflmpfiyCA==:117 a=IkcTkHD0fZMA:10 a=y4yBn9ojGxQA:10 a=z6gsHLkEAAAA:8 a=RpNjiQI2AAAA:8 a=AKTmbaUPI3psir6HZzAA:9 a=jpIH26JlB8aEU1M81S3jpgcb7nU=:19 a=QEXdDO2ut3YA:10 a=d-OLMTCWyvARjPbQ-enb:22 X-SEG-SpamProfiler-Score: 0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/27/20 3:30 PM, Paul Moore wrote: > On Wed, Aug 26, 2020 at 11:06 AM peter enderborg > wrote: >> On 8/26/20 4:45 PM, Paul Moore wrote: >>> On Wed, Aug 26, 2020 at 10:34 AM peter enderborg >>> wrote: >>>> On 8/26/20 3:42 PM, Paul Moore wrote: >>>>> On Mon, Aug 24, 2020 at 9:23 AM Peter Enderborg >>>>> wrote: >>>>>> This adds tracing of all denies. They are grouped with trace_seq for >>>>>> each audit. >>>>>> >>>>>> A filter can be inserted with a write to it's filter section. >>>>>> >>>>>> echo "permission==\"entrypoint\"" > events/avc/selinux_denied/filter >>>>>> >>>>>> A output will be like: >>>>>> runcon-1046 [002] .N.. 156.351738: selinux_denied: >>>>>> trace_seq=2 result=-13 >>>>>> scontext=system_u:system_r:cupsd_t:s0-s0:c0. >>>>>> c1023 tcontext=system_u:object_r:bin_t:s0 >>>>>> tclass=file permission=entrypoint >>>>>> >>>>>> Signed-off-by: Peter Enderborg >>>>>> --- >>>>>> include/trace/events/avc.h | 37 +++++++++++++++++++++++++++++++++++++ >>>>>> security/selinux/avc.c | 27 +++++++++++++++++++++++++-- >>>>>> 2 files changed, 62 insertions(+), 2 deletions(-) >>>>> My most significant comment is that I don't think we want, or need, >>>>> two trace points in the avc_audit_post_callback() function. Yes, I >>>>> understand they are triggered slightly differently, but from my >>>>> perspective there isn't enough difference between the two tracepoints >>>>> to warrant including both. However, while the tracepoints may be >>>> We tried that but that was problematic too. >>> My apologies if I was on that thread, but can you remind me why it was >>> a problem? Why can't we use a single tracepoint to capture the AVC >>> information? >> The problem is parsing the event. >> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2020_8_18_842&d=DwIBaQ&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc&r=oO5HuGEGxznA2F3djiiYxmxxWQonw0h6Sks-BEoB4ys&m=qmi2ROWsLC_0mLLhHkpb71j1YoicydLh-7l4cOsLYcY&s=iS3eZr3TFrN5I7BbnvPFYOKd6DfW1FHTFcwI7joS_fk&e= >> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2020_8_21_526&d=DwIBaQ&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc&r=oO5HuGEGxznA2F3djiiYxmxxWQonw0h6Sks-BEoB4ys&m=qmi2ROWsLC_0mLLhHkpb71j1YoicydLh-7l4cOsLYcY&s=9OsLN0Y5mUWxEAAqUE6K4PS57Pn1XyZz7GXak6uc_Ls&e= >> >> and the "single list" version >> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2020_8_17_1346&d=DwIBaQ&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7-GLPtvShAo4cc&r=oO5HuGEGxznA2F3djiiYxmxxWQonw0h6Sks-BEoB4ys&m=qmi2ROWsLC_0mLLhHkpb71j1YoicydLh-7l4cOsLYcY&s=tWSY2ry2IT6RcT5BIUwMuqBL_yPObDE1VljbLqI1zrA&e= >> >> With this patch we follow standard message format so no plugin should be needed. > I'm evidently missing something very fundamental (likely), and/or I'm > just not communicating very clearly (also likely), because the above > links don't appear to make any sense with respect to my question. > > Let me try a reset ... Why can't we basically take the > "selinux_denied" TRACE_EVENT implementation in your patch and use it > to replace the "selinux_audited" TRACE_EVENT in the selinux/next tree > (of course with the necessary changes to the AVC callback code)? > > If the "selinux_denied" implementation is valid from a tracing point > of view, why can we not do this? Of course if the "selinux_denied" > implementation is not a valid TRACE_EVENT then I'm not sure why this > was suggested for SELinux :) > Im happly fine with replacing the selinux_audited with selinux_denied.  However it is the case where there are more than one denial at the same time. Im not sure how and when it might happen. When that happen we got more than one event. I have no problems with that, but im not sure if the debug tools and perf can make sense of that. A other feature with the selinux_audited event it might be inserted on other places in the code too.  A denial is sort of final.