Review for Source Package: sysprof [Summary] MIR team ACK
While not the biggest attack surface, it could get crafted external data which is a common way. Hence IMHO this does need a security review, I'll assign ubuntu-security. List of specific binary packages to be promoted to main: sysprof, libsysprof-6-6, libsysprof-6-modules, libsysprof-capture-4-dev, libsysprof-6-dev Specific binary packages built, but NOT to be promoted to main: n/a Notes: Required TODOs: - none Recommended TODOs: - #1 The package should get a team bug subscriber before being promoted as you know and already wrote, but as usual that can be done once it is supposed to be promoted. [Rationale, Duplication and Ownership] - There is no other package in main providing the same functionality. It is augmenting the console use cases of perf, but there is nothing in main that has the same workflow and visualization. - A team is committed to own long term maintenance of this package. - The rationale given in the report seems valid and useful for Ubuntu [Dependencies] OK: - no other Dependencies to MIR due to this (libdex and libpanel already filed) - no -dev/-debug/-doc packages that need exclusion - libsysprof-6-dev has dependencies, but they are all in main - libsysprof-capture-4-dev only has internal dependencies - No dependencies in main that are only superficially tested requiring more tests now. Problems: None [Embedded sources and static linking] OK: - no embedded source present - no static linking - does not have unexpected Built-Using entries - not a go package, no extra constraints to consider in that regard - not a rust package, no extra constraints to consider in that regard Problems: None [Security] OK: - history of CVEs does not look concerning - does not run a daemon as root - does not use webkit1,2 - does not use lib*v8 directly - does not expose any external endpoint (port/socket/... or similar) - does not process arbitrary web content - does not use centralized online accounts - does not integrate arbitrary javascript into the desktop - does not deal with system authentication (eg, pam), etc) - does not deal with security attestation (secure boot, tpm, signatures) - does not deal with cryptography (en-/decryption, certificates, signing, ...) - this makes appropriate (for its exposure) use of established risk mitigation features Problems: - Does parse data formats (files [images, video, audio, xml, json, asn.1], network packets, structures, ...) from an untrusted source. An explicit use case mentioned is people attaching such profiles to bugs. [Common blockers] OK: - does not FTBFS currently - does have a test suite that runs at build time - test suite fails will fail the build upon error. - does have a test suite that runs as autopkgtest while the tests are superficial, they cover reverse dep failures - In addition you have already defined [1] which covers for what is left like how things "look like". [1]: https://wiki.ubuntu.com/DesktopTeam/TestPlans/Sysprof - The manual test might in the future be automated, but all together are a great set of tests and satisfies what we look for as a minimum - This does not need special HW for build or test - no new python2 dependency Problems: None [Packaging red flags] OK: - Ubuntu does not carry a delta - symbols tracking is in place. - debian/watch is present and looks ok - Upstream update history is ok - Debian/Ubuntu update history is ok - the current release is packaged - promoting this does not seem to cause issues for MOTUs that so far maintained the package - no massive Lintian warnings (the few we have are resonable IMHO) - debian/rules are rather clean - It is not on the lto-disabled list Problems: None [Upstream red flags] OK: - no Errors/warnings during the build - no incautious use of malloc/sprintf (as far as we can check it) - no use of user nobody - no use of setuid / setgid - no important open bugs (crashers, etc) in Debian or Ubuntu - no dependency on webkit, qtwebkit or libseed - part of the UI, desktop file is ok - translation (of the help AFAICS) is present Problems: - no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH. This is not so much of a problem as it would usually be, as it is a conceptual part of the design. It needs to peload to insert mem tracking (just like other memory profilers). It needs to get root permissions to ptrace. But that is not unexpected and asks the user about granting permissison. The only drawback is that therefore the attack severity (if there is one) is higher. Gladly for the most likely attack surface (manipulated profile data) there is no elevated permission needed (that is only for profiling) ** Changed in: sysprof (Ubuntu) Assignee: Christian Ehrhardt (paelzer) => Ubuntu Security Team (ubuntu-security) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2066269 Title: [MIR] sysprof To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sysprof/+bug/2066269/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
