[MIR] iotop-c

Bug #2137520 reported by Renan Rodrigo
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
iotop-c (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

[Availability]
The package iotop-c is already in Ubuntu universe.
The package iotop-c 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/iotop-c

[Rationale]
iotop-c (https://github.com/Tomas-M/iotop) is a maintained and improved version of the obsolete (and seems unmaintained) iotop.
We want to promote iotop-c to main and demote iotop, as the former seems to be the best choice for Ubuntu moving forward.
Other distributions, such as Fedora, have already replaced iotop with iotop-c. See: https://fedoraproject.org/wiki/Changes/Replace_iotop_with_iotop-c

This is the first time package will be in main.

The source builds a single binary package, iotop-c, and the debug symbols.

The package iotop-c is required in Ubuntu main no later than Feature Freeze - but the sooner the better, as always (:

[Security]
The package had apparently no security issues in the past.
- checked https://cve.mitre.org/cve/search_cve_list.html
- checked 'site:www.openwall.com/lists/oss-security iotop iotop-c'
- checked https://ubuntu.com/security/cve?package=iotop-c
- chcked https://security-tracker.debian.org/tracker/source-package/iotop-c
And there is nothing

No `suid` or `sgid` binaries
Binary `iotop-c` (linked to `iotop`, and alternatives) in sbin. It is no problem because it is a system administration tool, which requires access to root privileges and kernel space information. i.e. The current python implementation of `iotop` is in sbin as well. The same scrutinity applied to the iotop maintenance apply to iotop-c.
The package does not install services, timers or recurring jobs

I am not a security specialist but there is no clear sign of dangerous patterns - except being in sbin, discussed above. A security person should definitely have the word here.
The packages does not open privileged ports (ports < 1024).
The package does not expose any external endpoints.
The package does not contain extensions.

[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 any long-term and/or critical open bugs
  - Ubuntu https://bugs.launchpad.net/ubuntu/+source/iotop-c/+bug
  - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=iotop-c
  - Upstream https://github.com/Tomas-M/iotop/issues

The package does not deal with exotic hardware we cannot support

[Quality assurance - testing]
The package does not run a test at build time because upstream has no test suite in place.
There were no autopkgtests either, but I added some, as seen in https://launchpad.net/~rr/+archive/ubuntu/mir-iotop-c
This ubuntu2 version should land in the archive soon, I will update this bug once it happens.

The package does have not failing autopkgtests right now, as seen in the test runs for this PPA.

[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
Link to a recent build log of the package: check builds in https://launchpad.net/~rr/+archive/ubuntu/mir-iotop-c
Lintian overrides are not present

This package does not rely on obsolete or about to be demoted packages.
This package has no python2 or GTK2 dependencies.

The package will not be installed by default

Packaging and build is easy, link to debian/rules: https://git.launchpad.net/ubuntu/+source/iotop-c/tree/debian/rules

[UI standards]
Application is end-user facing, but a terminal-only tool, no desktop files included.
Translation is not present, but also less relevant for a system administration terminal tool.

[Dependencies]
Used check-mir from ubuntu-dev-tools to validate all dependencies or recommends are in main.

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

[Maintenance/Owner]
The owning team will be Ubuntu Server, and I have their acknowledgment for that commitment
The team is not yet subscribed, but will subscribe to the package before promotion - proof will be attached here.
<TBD>
This MIR will also allow Ubuntu Server to unsubscribe from iotop and demote it.

This does not use static builds
This does not use vendored code
This package is not rust based

The package has been built within the last 3 months in PPA: https://launchpadlibrarian.net/842411153/buildlog_ubuntu-resolute-amd64.iotop-c_1.30-1~ppabuild1_BUILDING.txt.gz

This change will not impact other teams.

[Background information]

The Package description explains the package well
Upstream Name is iotop (as it's an alternative/replacement to iotop)
Link to upstream project: https://github.com/Tomas-M/iotop

Tags: sec-8380
Renan Rodrigo (rr)
Changed in iotop-c (Ubuntu):
assignee: nobody → Renan Rodrigo (rr)
status: New → In Progress
Revision history for this message
Renan Rodrigo (rr) wrote :

$ lintian --pedantic
W: iotop-c source: newer-standards-version 4.7.2 (current is 4.6.2)
W: iotop-c source: orig-tarball-missing-upstream-signature iotop-c_1.30.orig.tar.xz

Renan Rodrigo (rr)
description: updated
Changed in iotop-c (Ubuntu):
assignee: Renan Rodrigo (rr) → nobody
status: In Progress → New
Changed in iotop-c (Ubuntu):
assignee: nobody → Pushkar Kulkarni (pushkarnk)
Renan Rodrigo (rr)
description: updated
Revision history for this message
Christian Ehrhardt (paelzer) wrote :

Ping for @pushkar, do you think you have a chance to get to that before today's sync?

Revision history for this message
Pushkar Kulkarni (pushkarnk) wrote :

> Ping for @pushkar, do you think you have a chance to get to that before today's sync?

Yes, will have it ready today.

Revision history for this message
Pushkar Kulkarni (pushkarnk) wrote (last edit ):
Download full text (4.8 KiB)

Review of source package: src:iotop-c

[Summary]
This is a proposal to replace the current Python-based iotop I/O monitoring tool with
iotop-c, an improved version written in C. The iotop-c upstream project has better
maintenance than (the almost unmaintained) iotop. The iotop package may be demoted
to universe.

MIR team ACK.

There is no CVE history. But the package will introduce a new superuser
binary (/usr/sbin/iotop-c). The security team might want to take a cursory
look, at the least. I'll assign ubuntu-security for now.

List of specific binary packages to be promoted to main: bin:iotop-c
Specific binary packages built, but NOT to be promoted to main: bin:iotop-c-dbgsym

Notes:
None.

Required TODOs:
None.

Recommended TODOs:
#0 - The package should get a team bug subscriber before being promoted
#1 - The current release (1.31) needs to be uploaded (needs a package merge with 1.31-1 in debian/sid).
#2 - The package does not have a test-suite that can be run at build-time. Consider contributing unit-tests upstream.
#3 - The build-warning note in [Upstream red flags] could be fixed by patching the Makefile.
#4 - Rule out memory leaks using a tool like valgrind.

[Rationale, Duplication and Ownership]
- There is no other package in main providing the same functionality.
  => The intention is to replace the iotop in main, with iotop-c; the former will be demoted
  back to universe.
- A team is committed to own long term maintenance of this package.
  => Server team
- The rationale given in the report seems valid and useful for Ubuntu

[Dependencies]
OK:
- no other runtime Dependencies to MIR due to this
- no other build-time Dependencies with active code in the final binaries to MIR due to this
- no -dev/-debug/-doc packages that need exclusion
- 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 parse data formats (files [images, video, audio,
  xml, json, asn.1], network packets, structures, ...) from
  an untrusted source.
- 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 (dropping permissions, using temporary environments,
  restricted users/groups, seccomp, systemd isolation features,
  apparmor, ...)
  => Needs sudo and the CAP_NET_ADMIN capability to run.

Problems: None

[Common bl...

Read more...

Changed in iotop-c (Ubuntu):
assignee: Pushkar Kulkarni (pushkarnk) → Ubuntu Security Team (ubuntu-security)
tags: added: sec-8380
Revision history for this message
Seth Arnold (seth-arnold) wrote :

During the MIR team meeting we discussed if this package actually needed a security review or not, and we decided to just give it a quick skim for a "gut check", rather than the full process.

It has the sort of very intricate C-string handling code that makes you wish it were written in Rust. But, it looks careful, and about the only thing I can think that would improve it is to change the memory allocation in routines such as get_vm_counters() and read_cmdlines() so that buffers aren't allocated, potentially grown, and discarded over and over again. (But maybe that's just my familiarity with Rust's easy and safe ability to re-use memory speaking.)

Let's skip a more detailed look.

Security team ACK to promote iotop-c to main.

Thanks

Changed in iotop-c (Ubuntu):
assignee: Ubuntu Security Team (ubuntu-security) → nobody
status: New → In Progress
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

So we have an MIR ACK in comment #4, and a security ACK in comment #5. Proceeding with team subscription and seed change.

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Seeds changed: https://code.launchpad.net/~rr/ubuntu-seeds/+git/ubuntu-seeds/+merge/499783
Team subscription added: https://code.launchpad.net/~canonical-server/+git/team-subscriptions/+merge/499784

Both changes should show up later in the day (subscription will become live, and seed change will trigger a component mismatch).

Revision history for this message
Christian Ehrhardt (paelzer) wrote :

Seeing the mismatch and the counterpart, subscription is applied.

# Mismatches:

Source and binary movements to main
iotop-c: iotop-c
MIR: #2137520 (In Progress)

Source and binary movements to universe (ubuntu-server)
iotop: iotop

# Nothing in proposed

$ rmadison -u ubuntu -s resolute,resolute-proposed iotop iotop-c
 iotop | 0.6-42-ga14256a-0.3build3 | resolute | source, amd64, amd64v3, arm64, armhf, ppc64el, riscv64, s390x
 iotop-c | 1.31-1 | resolute/universe | source, amd64, amd64v3, arm64, armhf, ppc64el, riscv64, s390x

# Acting

$ ./change-override --component main --suite resolute --source-and-binary iotop-c
Override component to main
iotop-c 1.31-1 in resolute: universe/misc -> main
iotop-c 1.31-1 in resolute amd64: universe/admin/optional/100% -> main
iotop-c 1.31-1 in resolute amd64v3: universe/admin/optional/100% -> main
iotop-c 1.31-1 in resolute arm64: universe/admin/optional/100% -> main
iotop-c 1.31-1 in resolute armhf: universe/admin/optional/100% -> main
iotop-c 1.31-1 in resolute ppc64el: universe/admin/optional/100% -> main
iotop-c 1.31-1 in resolute riscv64: universe/admin/optional/100% -> main
iotop-c 1.31-1 in resolute s390x: universe/admin/optional/100% -> main
Override [y|N]? y
8 publications overridden.
$ ./change-override --component universe --suite resolute --source-and-binary iotop
Override component to universe
iotop 0.6-42-ga14256a-0.3build3 in resolute: main/admin -> universe
iotop 0.6-42-ga14256a-0.3build3 in resolute amd64: main/admin/optional/100% -> universe
iotop 0.6-42-ga14256a-0.3build3 in resolute amd64v3: main/admin/optional/100% -> universe
iotop 0.6-42-ga14256a-0.3build3 in resolute arm64: main/admin/optional/100% -> universe
iotop 0.6-42-ga14256a-0.3build3 in resolute armhf: main/admin/optional/100% -> universe
iotop 0.6-42-ga14256a-0.3build3 in resolute ppc64el: main/admin/optional/100% -> universe
iotop 0.6-42-ga14256a-0.3build3 in resolute riscv64: main/admin/optional/100% -> universe
iotop 0.6-42-ga14256a-0.3build3 in resolute s390x: main/admin/optional/100% -> universe
Override [y|N]? y
8 publications overridden.

Changed in iotop-c (Ubuntu):
status: In Progress → Fix Committed
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.