Linux security - program attempts to ptrace everything - is this behavior suspicious enough that I should immediately nuke and reinstall?

I noticed that a couple of programs in my system attempt to ptrace other things seemingly at random, and by other things, I mean a lot of other things. I did verify the hashes for the binary and libraries linked that are listed in /proc/$(pidof )/maps against those of a ““clean”” recently installed VM and they match… But, this is really weird behavior, isn’t it?

ALLOWED nemo ptrace comm=pool-nemo requested_mask=read denied_mask=read peer=pipewire
ALLOWED nemo ptrace comm=pool-nemo requested_mask=read denied_mask=read peer=wireplumber
ALLOWED nemo ptrace comm=pool-nemo requested_mask=read denied_mask=read peer=unconfined
ALLOWED nemo ptrace comm=pool-nemo requested_mask=read denied_mask=read peer=hyprland
ALLOWED nemo ptrace comm=pool-nemo requested_mask=read denied_mask=read peer=xwayland
ALLOWED nemo ptrace comm=pool-nemo requested_mask=read denied_mask=read peer=hyprpaper
ALLOWED nemo ptrace comm=pool-nemo requested_mask=read denied_mask=read peer=waybar

I even checked the system with kaspersky’s antivirus tool for linux. It found nothing. Is there anything I can do to look further into this, other than simply to reinstall?

It’s probably benign, as most syscalls are.

Looking into it further, it seems that attempting to read from /proc/@{pid} triggers the ptrace complaints (sources: TechnicalDoc_Proc_and_ptrace · Wiki · AppArmor / apparmor · GitLab , [Metricbeat] Metricbeat invokes ptrace leading to AppArmor complaints · Issue #6932 · elastic/beats · GitHub ) even though the program itself isn’t necessarily invoking ptrace. I think this makes sense given that nemo is a file manager. Whew.