selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Thiébaud Weksteen" <tweek@google.com>
To: peter enderborg <peter.enderborg@sony.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Paul Moore <paul@paul-moore.com>, Nick Kralevich <nnk@google.com>,
	Joel Fernandes <joelaf@google.com>,
	Stephen Smalley <stephen.smalley.work@gmail.com>,
	Eric Paris <eparis@parisplace.org>,
	Ingo Molnar <mingo@redhat.com>,
	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Rob Herring <robh@kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	SElinux list <selinux@vger.kernel.org>
Subject: Re: [PATCH] RFC: selinux avc trace
Date: Fri, 31 Jul 2020 13:07:50 +0200	[thread overview]
Message-ID: <CA+zpnLd+bTbhiVutj=DpfTHkJFsXqodu+PekqTPDcBB+UKsoaw@mail.gmail.com> (raw)
In-Reply-To: <80a23580-5067-93b0-53fa-3bd53253c056@sony.com>

Thanks Peter, this looks like a great start.

> Perhaps the two of you could work together to come up with a common
tracepoint that addresses both needs.

Agreed.

> 1 Filtering. Types goes to trace so we can put up a filter for contexts or type etc.

That's right. I think this is the main reason why we would need
further attributes in the trace event.

> 2 It tries also to cover non denies.  And upon that you should be able to do coverage tools.
> I think many systems have a lot more rules that what is needed, but there is good way
> to find out what.  A other way us to make a stat page for the rules, but this way connect to
> userspace and can be used for test cases.

This is a great idea too.

>> On the one hand, we don't need/want to duplicate the avc message
>> itself; we just need enough to be able to correlate them.
>> With respect to non-denials, SELinux auditallow statements can be used
>> to generate avc: granted messages that can be used to support coverage
>> tools although you can easily flood the logs that way.  One other
> That is one reason to use trace.

Yes, that's right. I don't have any concern about the flooding here.
As Peter mentioned, trace is specially designed for this purpose.

On the patch, few things to note:

> ---
> +#include <linux/tracepoint.h>
> +TRACE_EVENT(avc_data,
> +        TP_PROTO(u32 requested,
> +             u32 denied,
> +             u32 audited,
> +             int result,
> +             const char *msg
> +             ),

I would not store the raw msg from avc. As we discussed, it is useful
to be able to match against the values we are seeing in the avc denial
message but these attributes should be simple (as opposed to
composite) so the filtering can easily be setup (see section 5.1 in
https://www.kernel.org/doc/Documentation/trace/events.txt). It makes
more sense extracting scontext and tcontext (for instance) which
allows for a precise filtering setup.

Here, I would also pass down the "struct selinux_audit_data" to avoid
a large list of arguments.

> +TRACE_EVENT(avc_req,
> +        TP_PROTO(u32 requested,
> +             u32 denied,
> +             u32 audited,
> +             int result,
> +             const char *msg,
> +             u32 ssid,
> +             struct selinux_state *state
> +             ),

I don't see that event being used later on. What was the intention here?

> +static int avc_dump_querys(struct selinux_state *state, char *ab, u32 ssid, u32 tsid, u16 tclass)
> +{
> +    int rc;
> +    char *scontext;
> +    u32 scontext_len;
> +    int rp;
> +
> +    rc = security_sid_to_context(state,ssid, &scontext, &scontext_len);
> +    if (rc)
> +        rp = sprintf(ab, "ssid=%d", ssid);
> +    else {
> +        rp = sprintf(ab, "scontext=%s", scontext);
> +        kfree(scontext);
> +    }
> +
> +    rc = security_sid_to_context(state, tsid, &scontext, &scontext_len);
> +    if (rc)
> +        rp +=sprintf(ab+rp, " tsid=%d", tsid);
> +    else {
> +        rp +=sprintf(ab+rp, " tcontext=%s", scontext);
> +        kfree(scontext);
> +    }
> +
> +    BUG_ON(!tclass || tclass >= ARRAY_SIZE(secclass_map));
> +    rp += sprintf(ab+rp, " tclass=%s", secclass_map[tclass-1].name);
> +    return rp;
> +}

As I mentioned before, this is literally repeating the avc audit
message. We are better off storing the exact fields we are interested
in, so that the filtering is precise.

Thanks

  parent reply	other threads:[~2020-07-31 11:08 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-24  9:15 [PATCH] selinux: add tracepoint on denials Thiébaud Weksteen
2020-07-24 13:32 ` Stephen Smalley
2020-07-24 13:54   ` Paul Moore
2020-07-28 12:49     ` Thiébaud Weksteen
2020-07-28 13:04       ` Stephen Smalley
2020-07-28 13:19         ` Thiébaud Weksteen
2020-07-28 13:12       ` Steven Rostedt
2020-07-28 13:23         ` Thiébaud Weksteen
2020-07-28 15:12       ` Paul Moore
2020-07-28 16:02         ` Thiébaud Weksteen
2020-07-28 16:19           ` Stephen Smalley
2020-07-28 16:20           ` Paul Moore
2020-07-30 15:50             ` Thiébaud Weksteen
2020-07-30  8:03           ` peter enderborg
2020-07-24 13:52 ` Steven Rostedt
2020-07-30 14:29   ` [PATCH] RFC: selinux avc trace peter enderborg
2020-07-30 14:50     ` Stephen Smalley
2020-07-30 15:47       ` peter enderborg
2020-07-30 15:04     ` Steven Rostedt
2020-07-30 15:31       ` peter enderborg
2020-07-30 16:02         ` Steven Rostedt
2020-07-30 17:05           ` peter enderborg
2020-07-30 17:16             ` Steven Rostedt
2020-07-30 19:12               ` peter enderborg
2020-07-30 19:29                 ` Steven Rostedt
2020-07-30 19:50                   ` peter enderborg
2020-07-31 11:07     ` Thiébaud Weksteen [this message]
2020-07-28 15:22 ` [PATCH] selinux: add tracepoint on denials Joel Fernandes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+zpnLd+bTbhiVutj=DpfTHkJFsXqodu+PekqTPDcBB+UKsoaw@mail.gmail.com' \
    --to=tweek@google.com \
    --cc=davem@davemloft.net \
    --cc=eparis@parisplace.org \
    --cc=joelaf@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab+huawei@kernel.org \
    --cc=mingo@redhat.com \
    --cc=nnk@google.com \
    --cc=paul@paul-moore.com \
    --cc=peter.enderborg@sony.com \
    --cc=robh@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=selinux@vger.kernel.org \
    --cc=stephen.smalley.work@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).