lkml.org 
[lkml]   [2020]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH] selinux: add tracepoint on denials
    On Tue, Jul 28, 2020 at 6:20 PM Paul Moore <paul@paul-moore.com> wrote:
    > I probably wasn't as clear as I should have been. I think it would be
    > helpful if you demonstrated how one would take the SELinux data in the
    > perf event and translated that into something meaningful.

    So the data itself is not that relevant. What is important is the
    ability to hook the kernel at the right location, at the right time.
    Here is an example on how this patch can be used on Android
    (simpleperf is the Android equivalent of perf), running dmesg as the
    shell user which is not permitted:
    # simpleperf record -e selinux:selinux_denied -a -g --duration 10
    # simpleperf report -g --full-callgraph
    Cmdline: /system/bin/simpleperf record -e selinux:selinux_denied -a -g
    --duration 10
    Arch: arm64
    Event: selinux:selinux_denied (type 2, config 493)
    Samples: 1
    Event count: 1

    Children Self Command Pid Tid Shared Object
    Symbol
    100.00% 0.00% dmesg 3511 3511
    /apex/com.android.runtime/lib64/bionic/libc.so __libc_init
    |
    -- __libc_init
    |
    -- main
    toybox_main
    toy_exec_which
    dmesg_main
    klogctl
    el0_svc_naked
    sys_syslog
    do_syslog
    security_syslog
    selinux_syslog
    avc_has_perm
    slow_avc_audit
    common_lsm_audit
    avc_audit_pre_callback

    You can see the combined user and kernel stacks which is useful to
    understand where and why the denial happened.
    The key point is that simpleperf is doing the heavy work (i.e names
    resolution), while the kernel only shares the strict minimum for that
    to happen.
    This can be correlated with the pid of the avc denial message (I'm
    assuming we are trouble shooting one specific denial).

    It is also possible to manually use ftrace. For instance, after
    enabling and triggering the denial:
    bonito:/sys/kernel/debug/tracing # cat trace
    # tracer: nop
    #
    # entries-in-buffer/entries-written: 1/1 #P:8
    #
    # _-----=> irqs-off
    # / _----=> need-resched
    # | / _---=> hardirq/softirq
    # || / _--=> preempt-depth
    # ||| / delay
    # TASK-PID CPU# |||| TIMESTAMP FUNCTION
    # | | | |||| | |
    dmesg-3624 [001] .... 13072.325358: selinux_denied: denied
    pid=3624 tclass=4 audited=2

    This can be correlated with the following avc denial:
    [ 2180.183062] type=1400 audit(1596111144.026:27): avc: denied {
    syslog_read } for comm="dmesg" scontext=u:r:shell:s0
    tcontext=u:r:kernel:s0 tclass=system permissive=0
    Here, there is limited value of having that tracepoint as we are only
    duplicating the avc message content.

    Nevertheless, the filtering part of Peter's patch would be useful to
    be more precise on which denial we are targeting (I'll reply to the
    other thread as well).
    I hope this clarifies the usage. Thanks.

    \
     
     \ /
      Last update: 2020-07-30 17:51    [W:4.042 / U:0.356 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site