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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2051850
Title:
[MIR] trace-cmd
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/trace-cmd/+bug/2051850/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
