[SCM] systemtap: system-wide probe/trace tool branch, master, updated. release-1.5-183-ged51cfa

[fche at sourceware dot org]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "systemtap: system-wide probe/trace tool".

The branch, master has been updated
       via  ed51cfa24ca27746ab09b59280b94117dd58cba3 (commit)
       via  4ecaadf545a729bb3e5f01f6f019716d49815d9a (commit)
      from  57fd81522e119db3ccaeacd54e4d518c8ca01a60 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit ed51cfa24ca27746ab09b59280b94117dd58cba3
Author: Josh Stone <jistone@redhat.com>
Date:   Mon Jul 25 11:48:31 2011 -0400

    CVE-2011-2503: read instead of mmap to load modules
    
    As staprun is preparing to load a kernel module, we first mmap the whole
    module as MAP_PRIVATE. Then we proceed with our security checks,
    including a trusted-signature validation on the mapped region, and if
    all checks out, we'll call init_module() with that same mapped region.
    
    However, MMAP(2) says of MAP_PRIVATE, "It is unspecified whether changes
    made to the file after the mmap() call are visible in the mapped
    region."  From my testing, it appears that file changes do indeed show
    up in our mapped memory.  This means we have a TOCTOU race between
    verifying the signature of that memory and then calling init_module().
    
    By using read() instead of mmap(), we ensure that we have a fully
    private copy of the module to verify and load, without fear of change.

commit 4ecaadf545a729bb3e5f01f6f019716d49815d9a
Author: Josh Stone <jistone@redhat.com>
Date:   Mon Jul 25 09:54:28 2011 -0400

    CVE-2011-2502: Don't allow path-based auth for uprobes
    
    For users that are only members of stapusr, and not stapdev, we only
    allow loading modules that are either signed with a trusted certificate
    or located in controlled paths.  For the script itself, that path is
    /lib/modules/.../systemtap/, and for uprobes it is the runtime.  When
    this policy was first written, uprobes only ever came from the runtime
    path, so the path check just returned 1 always.
    
    Later, commit 474d17ad added an optional argument to staprun -u, to
    allow the user to specify their own signed copy of uprobes to load.
    Unfortunately, if presented with an unsigned module, that would still
    fall back to the path check, which blissfully approved it anyway.
    
    Our policy is now that stapusr can only load a signed uprobes.ko, so the
    path check for uprobes now unconditionally returns 0.

-----------------------------------------------------------------------

Summary of changes:
 runtime/staprun/staprun_funcs.c |   54 +++++++++++++++++++++++++++-----------
 1 files changed, 38 insertions(+), 16 deletions(-)


hooks/post-receive
--
systemtap: system-wide probe/trace tool