From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 136D8C433E1 for ; Thu, 27 Aug 2020 13:36:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DF6E4207CD for ; Thu, 27 Aug 2020 13:36:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=paul-moore-com.20150623.gappssmtp.com header.i=@paul-moore-com.20150623.gappssmtp.com header.b="BnewPwO8" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727864AbgH0NgX (ORCPT ); Thu, 27 Aug 2020 09:36:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48822 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727877AbgH0Nal (ORCPT ); Thu, 27 Aug 2020 09:30:41 -0400 Received: from mail-ej1-x642.google.com (mail-ej1-x642.google.com [IPv6:2a00:1450:4864:20::642]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CC349C06123C for ; Thu, 27 Aug 2020 06:30:18 -0700 (PDT) Received: by mail-ej1-x642.google.com with SMTP id s19so2331650eju.6 for ; Thu, 27 Aug 2020 06:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m3bZHQbkUK7ru+mSIlVCeklpmkkabE1NV08rauGz/SA=; b=BnewPwO81kBvVFqomm9QXypRQ1vKnYBm3Xuds0ivqXpKN6sew0LIMekfam22SF/fZF ucvahfcOXZOCnVhnEJXEHozHM8Yg3MAzKX/Dlc2etkqT9cT67PAgKlx5jSY3w4Vc7UP/ lA3xGIcK8+LhYi2uldqLp0dH4t2gv5tLikb6a2HDm/dyQxVTBpngvVTgdZd9gKq6Gn/t jHoyRFQRNFNA+TseGZYKIsSYd4K/zk+Mn+LvlMRPwmXNo/Xe+A+tge1nVKqRGYohjCRE LKfWAuXpyZnKZSiojtR/FVgGa3Qkiof15CDWFMvtTLK1jIgm5Y6A/Pt4nRnHsJ2IHL6u /Kjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m3bZHQbkUK7ru+mSIlVCeklpmkkabE1NV08rauGz/SA=; b=ZtmVHMf4oBiT1DTcd0cUOciWsnCysbQUMhjvqdV+8jF9KJrqYD/8HCxoKNYxAa7E/M QKfS1swlrzipLm+gSH78drh13syKR/8XW/fCiAKitXdLNDwx9C8dEDnV1LYzeCjA1sA7 pN9Bl/5y0Pi3U0tMbMlwsUHHeMoTD4/zfVxptOqtHXZTFc+8sNSNzdP+OaztR6s6oucJ 9fR/TXtj/AVxjbP2HKdxYG90MoKudizmuF6KQqiKfwaelsG1tDeslbLTXt5CpwrdC9hK SJBjhlpQju0l52to7no/8qbO8lMInAwcTj5E/ms73G1zngfD3dOJFEpcdqEpnOnnBVdN +CjA== X-Gm-Message-State: AOAM532KLY1hnTXmJZD/PFAo8gFuxgzjKIprkfi3FSPI6vUq47Dly6A6 CbzlgLxhwXgzhkJDw0yE990F/dYwopyAKK7N5HBA X-Google-Smtp-Source: ABdhPJxjQNf2tUYMG8mTbfyZlnlvWwxh2T296na0R444Fnqj3QwzjsW5Kea1i/+9tcu0OeYYDuxkPOxpkx+bIs7B5pc= X-Received: by 2002:a17:906:7c46:: with SMTP id g6mr20387671ejp.178.1598535017320; Thu, 27 Aug 2020 06:30:17 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <59fa190f-37c0-79f3-ea46-8f821d820e1c@sony.com> From: Paul Moore Date: Thu, 27 Aug 2020 09:30:05 -0400 Message-ID: Subject: Re: [RFC PATCH] selinux: Add denied trace with permssion filter To: peter enderborg Cc: linux-kernel@vger.kernel.org, SElinux list , Steven Rostedt , Stephen Smalley 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, 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://lkml.org/lkml/2020/8/18/842 > > https://lkml.org/lkml/2020/8/21/526 > > and the "single list" version > > https://lkml.org/lkml/2020/8/17/1346 > > 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 :) -- paul moore www.paul-moore.com