[Bug 2051850] Re: [MIR] trace-cmd

Mark Esler 2051850 at bugs.launchpad.net
Tue Mar 26 19:59:36 UTC 2024 

I reviewed trace-cmd 3.2-1 as checked into noble. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

> TRACE-CMD: The front-end application to Ftrace. The back-end
application to KernelShark.

- CVE History
  - none
- Build-Depends
  - most are for docs
  - libtrace* mirs are ack'd
  - note the d/control suggestion for installing kernelshark
    - trace-cmd is the backend for kernelshark
    - https://git.kernel.org/pub/scm/utils/trace-cmd/kernel-shark.git/
- pre/post inst/rm scripts
  - none
- init scripts
  - none
- systemd units
  - none
- dbus services
   - none
- setuid binaries
  - none
- binaries in PATH
  - root owned ./usr/bin/trace-cmd
- sudo fragments
  - none
- polkit files
  - none
- udev rules
  - none
- cron jobs
  - none
- unit tests / autopkgtests
  - needs tests, see MIR team's requirements
- Build logs
  - -Walloc-size-larger-than=
  - -Wformat-overflow=
  - -Wunused-result
  - please do not use in production environments

- Processes spawned
  - moderate use, as expected by nature of program
  - root user privileges are expected when using this tool
  - checked uses and attempts looks okay
  - in traceinput.c, regexec() is controlled by root unprivileged user
  - note that arbitrary commands can be specified to run based on tracing triggers
- Memory management
  - extremely heavy use
  - this code is unlikely safe to be used in production. this is meant for development.
    - we should never suggest usecases that input is untrusted
      - e.g., network traffic from untrusted sources
- File IO
  - heavy use
- Logging
  - some use of tracecmd_debug(), mostly perror()
- Environment variable usage
  - TRACECMD_PLUGIN_DIR, HOME, USER, LOGNAME, PATH
  - mostly used to run commands as another user
- Use of privileged functions
  - setuid, setgid, ioctl, initgroups
  - used to run arbitrary commands as an abitrary user by record_trace_command()
  - ioctl used to get the local context id of a vm socket
    - hardcoded to use Linux Kernel constant 0x7b9 +1
    - see https://github.com/mdlayher/vsock/blob/main/fd_linux.go and past ioctl_linux.go iteration
- Use of cryptography / random number sources etc
  - none
- Use of temp files
  - safe use of mkstemp
- Use of networking
  - yes, heavy socket use
- Use of WebKit
  - none
- Use of PolicyKit
  - none

- Any significant cppcheck and Coverity results
  - many results, most are likely false-positives
  - potential memory leaks caused by jumps
  - treating these as bugs in a _development tool_
    - this is not meant for _production_
  - checked OOB reports are false-positives
- Any significant shellcheck results
  - none
- Any significant bandit results
  - none
- Any significant govulncheck results
  - none
- Any significant Semgrep results
  - none
  - noisy rule complains about strtok v. strtok_r
    - see tracecmd/trace-cmd.c:53
    - proper use is understood

Security is content to review this as a _development tool_. Extreme
caution should be taken if used in production.

Security team ACK for promoting trace-cmd to main.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to trace-cmd in Ubuntu.
https://bugs.launchpad.net/bugs/2051850

Title:
  [MIR] trace-cmd

Status in trace-cmd package in Ubuntu:
  Incomplete

Bug description:
  [Availability]
  The package trace-cmd is already in Ubuntu universe (Debian sync)
  The package trace-cmd build for the architectures it is designed to work on.
  It currently builds and works for architectures: amd64, arm64, armhf, ppc64el, riscv64, s390x
  Link to package https://launchpad.net/ubuntu/+source/trace-cmd

  [Rationale]
  - The package trace-cmd is required in Ubuntu main to help improve the experience of performance engineers working with Ubuntu
  - The package trace-cmd will not generally be useful for a large part of our user base, but is helpful still because it will help enhance application developer experience while trying to find performance gain.
  - There is no other/better way to solve this that is already in main or should go universe->main instead of this.
  - The package trace-cmd is required in Ubuntu main no later than Feb 29 2024 (Feature Freeze) due to the will to have performance/tracing tools in Noble (LTS).

  [Security]
  - No CVEs/security issues in this software in the past. But one bug regarding a buffer overflow was found (see LP: #1955129) but not clearly identified as CVE/security bug.
  - No `suid` or `sgid` binaries
  - No executable in `/sbin` and `/usr/sbin`
  - Package does not install services, timers or recurring jobs.
  - Based on some quick tests, it looks like running trace-cmd is only making sense if run as root.
  - Package can open privileged ports (ports < 1024) to listen for incoming connections to receive traces.
  - I did not notice any use of apparmor/seccomp or any feature that could help mitigate an exploitation.
  - Based on the previous elements, a more in-depth security review might be recommended.
  - Packages does not contain extensions to security-sensitive software (filters, scanners, plugins, UI skins, ...)

  [Quality assurance - function/usage]
  - The package works well right after install

  [Quality assurance - maintenance]
  - The package is maintained well in Debian/Ubuntu/Upstream and does
     not have too many, long-term & critical, open bugs
    - Ubuntu https://bugs.launchpad.net/ubuntu/+source/trace-cmd/+bug
    - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=trace-cmd
    - Upstream's bug tracker https://bugzilla.kernel.org/buglist.cgi?component=Trace-cmd%2FKernelshark
  - The package does not deal with exotic hardware we cannot support

  [Quality assurance - testing]
  - The package does have a test suite but it is not run at build time. I will submit a patch to do so.
  - The package runs an autopkgtest, but is a "superficial" one. It is currently passing on amd64, arm64, ppc64el, s390x:
    - https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/amd64/t/trace-cmd/20240117_073638_c1c31@/log.gz
    - https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/arm64/t/trace-cmd/20240119_054257_84abe@/log.gz
    - https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/ppc64el/t/trace-cmd/20240117_070636_bdbfa@/log.gz
    - https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/s390x/t/trace-cmd/20240117_070802_84abe@/log.gz
  - The package does have failing autopkgtests for armhf tests right now, but it seems they always failed. A quick look at the error (Permission denied) suggest it might be fixable.

  [Quality assurance - packaging]
  - debian/watch is present and works
  - debian/control defines a correct Maintainer field
  - This package does not yield massive lintian Warnings, Errors
  - Lintian overrides are not present
  - This package does not rely on obsolete or about to be demoted packages.
  - The package is planned to be installed by default, but does not ask debconf questions
  - Packaging and build is easy https://git.launchpad.net/ubuntu/+source/trace-cmd/tree/debian/rules

  [UI standards]
  - Application is not end-user facing (does not need translation)

  [Dependencies]
  - There are further dependencies that are not yet in main, MIR for them will follow:
    - https://bugs.launchpad.net/ubuntu/+source/libtraceevent/+bug/2051916
    - https://bugs.launchpad.net/ubuntu/+source/libtracefs/+bug/2051925

  [Standards compliance]
  - This package correctly follows FHS and Debian Policy

  [Maintenance/Owner]
  - The owning team will be Foundations and I have their acknowledgement for that commitment
  - The future owning team is not yet subscribed, but will subscribe to the package before promotion
  - The current bug subscriber (~chasedouglas) does not seem to be active anymore. Should we replace them by someone else?
  - This does not use static builds
  - This does not use vendored code
  - The package was test rebuilt in a PPA recently https://launchpadlibrarian.net/712030593/buildlog_ubuntu-noble-amd64.trace-cmd_3.2-1build1_BUILDING.txt.gz

  [Background information]
  The Package description explains the package well.
  Upstream Name is trace-cmd
  Link to upstream project https://git.kernel.org/pub/scm/utils/trace-cmd/trace-cmd.git/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/trace-cmd/+bug/2051850/+subscriptions

More information about the foundations-bugs mailing list