> A rootkit doesn't need to be remote and the user isn't necessarily an attacker.
No one said a rootkit needs to be remote. (I used "remote" in quotes just to align it to the backdoor.) And in the context of security, it is definitely an attack. If there's not a user executing unauthorized commands, then it's simply installed and authorized software.
> It doesn't need to have any functionality for user interaction...
This is true, and I can see how some of my statements were maybe a bit more specific about this than they needed to be. The point is still to give an attacker a context with elevated permissions; it need not be an interactive context.
> It runs with the same privileges as the OS that it is part of.
This I still think is overly restrictive. I don't think running in ring 0/1/2 with the kernel and drivers is a necessary component; having "root" access such that it can invoke kernel functionality necessary to achieve its goals is sufficient. Now, it may use "root" access to modify kernel files and drivers, which is perhaps what you're referring to and where the line blurs and pedantry beings. If "root" access gives you unfettered access to the system, including modifying kernel executable files, then there is basically no difference between "root" and ring 0.
> For example, by your definition: a remotely accessible privileged service is a rootkit, because an unprivileged internet user can interact with it - accessing data and executing code in the service's privileged context. 'sudo nginx' is not a rootkit.
More pedantry. Clearly intended and authorized access to a service is just normal operation. This is why I'm very explicit about the usage being unauthorized and label the user an "attacker".