SUID stands for Set User ID. An SUID binary is a file that is always run with the UID of the owner user (almost always root). Note that this does not require that the user running them has root permissions, the UID is always changed. For instance, the ping command needs to set up network sockets, which requires root permissions, but is also often used by non-root users to check their network connections. Instead of having to sudo ping, any normal user is able to just run ping, as it uses SUID to run as the root user. sudo and doas also require functions that necessitate them running as root, and so if you can find out how to exploit these commands to run some arbitrary code without having to authenticate (since authentication happens after the binary has started running), there is a potential for vulnerabilities. Specifically, there is the privilege escalation, which is one of the most severe types of vulnerabilities.

run0 starts using systemd-run, which does not use SUID. Instead, it runs with the permissions of the current user, and then authenticates to the root user after the binary has already started to run. systemd-run contacts polkit for authentication, and if it succeeds, it creates a root PTY (pseudo-terminal/virtual terminal), and sends information between your session and the root PTY. So this means that in order to achieve privilege escalation with run0 as root, you have to actually authenticate first, removing the “before authentication” attack surface of sudo and doas.

TL;DR SUID binaries will always run as the owner (usually root), even before any form of authentication. run0 will start with the permissions of the current user, and then authenticate before running anything with root permissions.