Dear Maintainer,

Slay does not send signals as root, slay runs `kill` as the slayee:

    su -m $slayee -c "kill $SIGNAL -1"

That `kill` therefore runs with env su sets up for that user, including any AppArmor confinement attached to the user's sessions (i.e. via pam_apparmor).
If you set up pam_apparmor properly, then running:

    su -m user -c 'cat /proc/self/attr/current'

will print a profile in enforce mode rather than "unconfined", and the `kill -1` is then confined by that profile.
Running kill with pid -1 sends the signal only to processes the caller is allowed to signal and silently skips the rest.
Based on the used apparmor profile, ability to kill "own" processes thus may be severely limited,
especially if some of those processes have either changed hat, or changed to a different profile that cannot be signalled from the original profile.
If the user running inside the restricted apparmod profile can find a way to abuse capability to change hat or profile, this can be used to evade slay.

Another way the slayee can easily use to avoid being slain is abusing fork bomb - if the user exhausts limit on number of processes (ulimit -u), execve in su's child fail and slay will be unable to kill any of that user's processes.

I suspect there may be more ways to become "immune" to slay (set shell to some exotic one that does not understand or can override "kill" command?)
although I have not found any additional ways than those two described during my brief experimentation.

Suggested fix: kill the user's processes as root instead of as the slayee.
Unconfined root is not subject to the slayee's AppArmor confinement and is not affected by the slayee's limits.