I'll look into this one now.

apart from the processlist_helper this package also ships ksgrd_network_helper
which has the cap_net_raw capability. The review we did for the latter in bug
1151190 was not too great in terms of code quality.

I am done with the processlist_helper. There is nothing too wrong with it
security wise but it has some quirks:

- sendsignal is racy in nature, since PIDs can be recycled. It's a pretty
  generic interface to send arbitrary signals to arbitrary PIDs. This has to
  be `auth_admin` forever.
- renice is even racier in nature and can fail by accident, since they
  try to renice each thread of a process via /proc/<pid>/task.
- changeioscheduler and changecpuscheduler: these are similar to renice. Here
  raw integer constant are passed for the io class, for example. This could be
  improved by passing string labels or properly casting from/to enums.

In all of these functions a nonsensical approach is found for specifying
multiple PIDs to operate on:

There is a `pidcount` integer and then for the count of PIDs the code looks
for further entries in the QVariantMap named `pid%i`. This is only bloating
the code and making everything more complex. They *do* have a QVariantMap
after all, so why not place a proper list or vector data structure in there?

Filed https://invent.kde.org/plasma/libksysguard/-/issues/4

I also had a look into the ksgrd_network_helper that runs with cap_net_raw
capability.

The program is a bit larger and uses libpcap to process the headers of all
IPv4/IPv6 packets that pass the system. Then /proc/<pid>/fd is crawled to
match socket inodes to process IDs. All of that stuff is then output on stdout
for consumption of other programs.

This program can easily be problematic, since it handles a lot of untrusted
data:

- the ethernet headers and IP headers of packets originated from other systems
  or unprivileged processes on the local system.
- the PID in /proc that are at least partially controlled by unprivileged
  local processes.

I looked into the critical code paths and it looks like all they do is reading
the IP address fields in the network packets and reading the symlinks in
/proc/<pid>/fd to check whether they are `socket:<inode>` files.

The PIDs, inodes and IP addresses along with some statistical data is only
used for display purposes. So in its current form it should be fine. There are
likely some non-security bugs in there though e.g. when multiple connections
to the same IP address occur.

Both components are okay security wise, apart from the smaller suggestions for
the processlisthelper. The component can be whitelisted after a quick
refresher when the kde6 release is coming closer.

The Git revision I reviewed so far is 3da755aa.

The package to be submitted is now in KDE:Frameworks/libksysguard6.

The changes since the review are nearly only noise, but they also renamed the
D-Bus interfaces for versioning. So it's good we didn't whitelist right away.

The issues reported in comment 4 have not been addressed by they are
non-security so we can start the whitelisting process.

The whitelisting is in Factory now. Closing as fixed.