[uidnobody]

in the case of systemd the pty remains user owned once the root program is attached, this allows any user process to read and hijack the root program. sudo, su and doas ymmv. The suggested fix for systemd is to chown the slave pty to the user privilege that matches the attached program to prevent misuse.

[bahorn]

I understand the issue, I have checked /dev/pts/ and seen systemd-run create a user readable pts there. I'm not adverse to that one getting chown()'d, but there really isn't any impact from it.

The problem is you can not hijack (meaning command exec right?) a root shell running under your account with this unless there is an approach that hasn't been mentioned yet. You can read character input, stopping the program from receiving input while you are doing so, of a process your user account directly started. I investigated the other ways and he hasn't given a viable one beyond running stuff directly in shell of the target session (TIOCSTI doesn't work if you target a different pty) or using ptrace.

All of these apply to other programs as even though they set root permissions on their pty as you can influence their parent. You need to chown both if you want to stop issues, but that'll probably break stuff. To be clear his whole point is that systemd is less secure compared to sudo etc but is using something that applies to everything to try and show that, involving using pocs that didn't even show the issues he was claiming, which is disingenuous.

[uidnobody]

so fix the issue by chown the pty created by systemd and give the OP his dues for pointing the issue out, seems like unnecessary flaming beyond that as to why this can be used to freely hijack root permissions with ptrace_classic and tty ioctls is a wider problem that should also be addressed and protected against when elevating rights. Microsoft "sudo.exe" doesnt have the same issue and fixed an insecure pipe permission quickly that allowed it. As for the boundary policy kit auth for systemd-run is one-shot meaning users should be prompted for each elevation request but looks to be persistent for the lifetime of the elevated process as policy kit is no longer requesting auth when the user does any of the three methods OP outlined.