I reviewed ubuntu-insights 0.5.0 as checked into questing. This shouldn't
be considered a full audit but rather a quick gauge of maintainability.
ubuntu-insights is a solution for reporting hardware information. It is
designed to be a replacement for ubuntu-report.
- CVE History
- None. The project is fairly new.
- Upstream project does not have a `SECURITY.md` file, and the GitHub
security advisories are not enabled. It is highly recommended that
the upstream repository include a `SECURITY.md` file stating how to
report security vulnerabilities.
- Build-Depends
- Normal build deps
- pre/post inst/rm scripts
- Some scripts automatically generated by `dh_installsystemduser` to
manage the systemd services. No issues here.
- init scripts
- None
- systemd units
- Two services, `ubuntu-insights-collect` and `ubuntu-insights-upload`
respectively. Both have `.service` and `.timer` files.
- The `ubuntu-insights-collect` service runs the `ubuntu-insights`
binary with the `collect` argument to presumably collect system
information. `.timer` specifies the runtime of the service 5 minutes
after boot, and every month.
- The `ubuntu-insight-upload` service runs the `ubuntu-insights` binary
with the `upload` argument instead. The `.timer` specifies in the
comments that it runs 5 minutes after boot but it actually runs 8
minutes after boot, every week.
- Both services use many restrictions and protections in their respective
`.service` systemd configurations. They seem adequate enough.
`CapabilityBoundingSet` can be used to restrict the service further
capability wise, which could be something to consider, but the
protections currently implemented seem to be fine. Also, there is no
umask entry for the systemd service, making the reports potentially
world readable, but proper permission management should mitigate this.
- dbus services
- None
- setuid binaries
- None
- binaries in PATH
- /usr/bin/ubuntu-insights
- sudo fragments
- None
- polkit files
- None
- udev rules
- None
- unit tests / autopkgtests
- Contains unit tests, which seem to be extensive.
- cron jobs
- None
- Build logs
- Seem normal
- Quite a few warnings/failures from one of the tests about executables
not being in PATH. This seems to be intended, however.
- Processes spawned
- Some calls can be adapted to golang instead of using `exec.Command`.
While `go build` can be difficult to execute as a golang function,
instead of using `cp` and `mkdir` with `exec.Command`, using golang
equivalent functions is recommended instead. However, this only happens
in a few instances, and the command is constructed safely, so this is
not an issue.
- Memory management
- N/A for golang.
- There is a small C file for interfacing with wayland. Memory allocation
seems to be fine there.
- File IO
- File IO seems to be fine. The application uses temporary files, created
with proper permissions, to write reports atomically.
- After a report has been generated, the application writes the report
to a json file, named with a UNIX timestamp. The directories seem to
be limited in the systemd service, limiting reading and writing to
`$HOME/.cache` and `$HOME/.config` respectively. The reports are
separated in constants "local" and "uploaded" directory names (in
`.cache` directory,
`$HOME/.cache/ubuntu-insights/linux/{local,uploaded}`).
- No issues here.
- Logging
- Logging overall seems to be fine. The application uses proper logging
implementations from golang standard library.
- When considering logging as part of report ingestion by the server, it
is important to consider how untrusted input is handled on the server
side. If a hardware named element is changed by the person sending the
report to include malicious input, this could lead to unintended
consequences. The server elements of ubuntu-insights do not seem to be
included in the package, and the data can be aggregated in many
different ways, making a wide range of attacks possible if input is not
properly sanitized by whichever agreggate system is used for the
uploaded reports.
- Environment variable usage
- Seems to be fine.
- Use of privileged functions
- None
- One of the vendored libraries maps a lot of architectural syscalls to
hex codes. But it does not seem like the application itself uses any
privileged functions.
- Use of cryptography / random number sources etc
- The application does use `math/rand` instead of `crypto/rand`, but it
specifies in the comments that cryptographic randomness is not needed.
Therefore, this is a deliberate choice. Looking at it, this seems to
only be used to generate a random wait timeout to make the application
sleep for the duration.
- Use of temp files
- The use of temp files seems to be secure, ensuring restrictive
permissions upon creation.
- Use of networking
- For uploading, the default server seems to be
`https://metrics.ubuntu.com`.
- The connection is done using the std `net/http` library.
- It also seems like golang automatically connects with TLS if the
server supports it. However, it does not seem like golang enforces
TLS, meaning that the connection could be downgraded to unencrypted
HTTP, transmitting the information insecurely. This should be taken
into consideration.
- Use of WebKit
- None
- Use of PolicyKit
- None
- Any significant cppcheck results
- None
- Any significant Coverity results
- Coverity detected 499 vulnerabilities.
- All of these vulnerabilities appear to be in vendored code. There is
also some application code inside the vendored directory, as the
application vendors `ubuntu-insights/common`.
- These detections do not seem critical, with most being for unchecked
errors.
- Any significant shellcheck results
- Nothing of note
- Any significant govulncheck results
- Some golang 1.22 vulnerabilities, but not package specific.
- These seem to have already been fixed in the Ubuntu golang-1.22
package.
- Any significant Semgrep results
- Nothing of note, except for the use of `math/rand` instead of
`crypto/rand` mentioned above.
Overall, the code seems to be readable and maintainable. While the upstream
is rather small and is composed of a few maintainers, the upstream is
Ubuntu itself which allows for easier collaboration in case of security
issues arising.
The only concern is the package vendoring. Some of the indirect
dependencies seem to no longer be maintained (such as `blackfriday` and
`go-difflib`), but the direct dependencies seem to be rather popular, or
the upstream for them is also Ubuntu itself. The package also seems to be
using proper systemd service isolations, and contains an extensive test
suite. However, care has to be put into parsing the submitted information
on the server side, ensuring that the report received by the server is
threated as untrusted, as the user is able to modify the hardware
information in the report which could potentially cause problems.
One security consideration for the upstream repository would be to create
a `SECURITY.md` indicating how to report security vulnerabilities, as well
as enabling GitHub Security Advisories for easier handling of security
issues.
Security team ACK for promoting ubuntu-insights to main, given that the
upstream repository takes the considerations given in the above paragraph
and create a proper security issue reporting policy.
** Changed in: ubuntu-insights (Ubuntu)
Assignee: Ubuntu Security Team (ubuntu-security) => (unassigned)
** Changed in: ubuntu-insights (Ubuntu)
Status: New => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2118794
Title:
[MIR] ubuntu-insights
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-insights/+bug/2118794/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
