All of lore.kernel.org
 help / color / mirror / Atom feed
From: peter enderborg <peter.enderborg@sony.com>
To: "Steven Rostedt" <rostedt@goodmis.org>,
	"Thiébaud Weksteen" <tweek@google.com>
Cc: Stephen Smalley <stephen.smalley.work@gmail.com>,
	Paul Moore <paul@paul-moore.com>, Nick Kralevich <nnk@google.com>,
	Joel Fernandes <joelaf@google.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>, Arnd Bergmann <arnd@arndb.de>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	SElinux list <selinux@vger.kernel.org>
Subject: Re: [PATCH v2 1/2] selinux: add tracepoint on denials
Date: Sat, 15 Aug 2020 09:17:07 +0200	[thread overview]
Message-ID: <4427545e-d4ea-b64e-91d9-3ccd2a483df1@sony.com> (raw)
In-Reply-To: <20200814134653.0ba7f64e@oasis.local.home>

On 8/14/20 7:46 PM, Steven Rostedt wrote:
> On Fri, 14 Aug 2020 19:22:13 +0200
> peter enderborg <peter.enderborg@sony.com> wrote:
>
>> On 8/14/20 7:08 PM, Stephen Smalley wrote:
>>> On Fri, Aug 14, 2020 at 1:07 PM peter enderborg
>>> <peter.enderborg@sony.com> wrote:  
>>>> On 8/14/20 6:51 PM, Stephen Smalley wrote:  
>>>>> On Fri, Aug 14, 2020 at 9:05 AM Thiébaud Weksteen <tweek@google.com> wrote:  
>>>>>> On Thu, Aug 13, 2020 at 5:41 PM Stephen Smalley
>>>>>> <stephen.smalley.work@gmail.com> wrote:  
>>>>>>> An explanation here of how one might go about decoding audited and
>>>>>>> tclass would be helpful to users (even better would be a script to do it
>>>>>>> for them).  Again, I know how to do that but not everyone using
>>>>>>> perf/ftrace will.  
>>>>>> What about something along those lines:
>>>>>>
>>>>>> The tclass value can be mapped to a class by searching
>>>>>> security/selinux/flask.h. The audited value is a bit field of the
>>>>>> permissions described in security/selinux/av_permissions.h for the
>>>>>> corresponding class.  
>>>>> Sure, I guess that works.  Would be nice if we just included the class
>>>>> and permission name(s) in the event itself but I guess you viewed that
>>>>> as too heavyweight?  
>>>> The class name is added in part 2. Im not sure how a proper format for permission
>>>> would look like in trace terms. It is a list, right?  
>>> Yes.  See avc_audit_pre_callback() for example code to log the permission names.  
>> I wrote about that on some of the previous sets. The problem is that trace format is quite fixed. So it is lists are not
>> that easy to handle if you want to filter in them. You can have a trace event for each of them. You can also add
>> additional trace event "selinux_audied_permission" for each permission. With that you can filter out tclass or permissions.
>>
>> But the basic thing we would like at the moment is a event that we can debug in user space.
> We have a trace_seq p helper, that lets you create strings in
> TP_printk(). I should document this more. Thus you can do:
>
> extern const char *audit_perm_to_name(struct trace_seq *p, u16 class, u32 audited);
> #define __perm_to_name(p, class, audited) audit_perm_to_name(p, class, audited)
>
> 	TP_printk("tclass=%u audited=%x (%s)",
> 		__entry->tclass,
> 		__entry->audited,
> 		__perm_to_name(__entry->tclass, __entry->audited))
>
>
> const char *audit_perm_to_name(struct trace_seq *p, u16 tclass, u32 av)
> {
> 	const char *ret = trace_seq_buffer_ptr(p);
> 	int i, perm;
>
> 	( some check for tclass integrity here)
>
> 	perms = secclass_map[tclass-1].perms;
>
> 	i = 0;
> 	perm = 1;
> 	while (i < (sizeof(av) * 8)) {
> 		if ((perm & av) && perms[i]) {
> 			trace_seq_printf(p, " %s", perms[i]);
> 			av &= ~perm;
> 		}
> 		i++;
> 		perm <<= 1;
> 	}
>
> 	return ret;
> }
>
> Note, this wont work for perf and trace-cmd as it wouldn't know how to
> parse it, but if the tclass perms are stable, you could create a plugin
> to libtraceevent that can do the above as well.
>
> -- Steve

That works fine. I will do this as third patch in our patch-set.  But I think we also should export the permission-map
somewhere. I don’t think there is any good place for it in tracefs. So selinuxfs or debugfs might do? And I think it is
more useful to print what is denied than what is audited but that does not match the trace event name.





  parent reply	other threads:[~2020-08-15 21:36 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-13 14:48 [PATCH v2 1/2] selinux: add tracepoint on denials Thiébaud Weksteen
2020-08-13 14:48 ` [PATCH v2 2/2] selinux: add basic filtering for audit trace events Thiébaud Weksteen
2020-08-13 15:05   ` Casey Schaufler
2020-08-13 15:35     ` peter enderborg
2020-08-13 15:49       ` Stephen Smalley
2020-08-13 16:10         ` peter enderborg
2020-08-13 17:14         ` peter enderborg
2020-08-13 17:38           ` Steven Rostedt
2020-08-13 18:18             ` peter enderborg
2020-08-13 19:16               ` Steven Rostedt
2020-08-13 15:41 ` [PATCH v2 1/2] selinux: add tracepoint on denials Stephen Smalley
2020-08-14 13:05   ` Thiébaud Weksteen
2020-08-14 16:51     ` Stephen Smalley
2020-08-14 17:07       ` peter enderborg
2020-08-14 17:08         ` Stephen Smalley
2020-08-14 17:22           ` peter enderborg
2020-08-14 17:46             ` Steven Rostedt
2020-08-14 18:06               ` peter enderborg
2020-08-14 18:30                 ` Steven Rostedt
2020-08-14 18:50                   ` peter enderborg
2020-08-14 18:56                     ` Steven Rostedt
2020-08-15  7:17               ` peter enderborg [this message]
2020-08-15  8:45               ` peter enderborg

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=4427545e-d4ea-b64e-91d9-3ccd2a483df1@sony.com \
    --to=peter.enderborg@sony.com \
    --cc=arnd@arndb.de \
    --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=robh@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=selinux@vger.kernel.org \
    --cc=stephen.smalley.work@gmail.com \
    --cc=tweek@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.