We're unlikely to expand the role of administrative power here, administrators intentionally have very little power. See:

https://secure.phabricator.com/book/phabricator/article/users/#administrators

In the general case, it's bad if a compromised administrative account has free reign to disable security rules, etc. The security model around Herald isn't quite as siloed as it could be around this specific attack, but that's the sort of thing that the general model of limited administrative power is trying to anticipate.

Today:

• Users with access to the Phabricator host can destroy the rule with bin/remove destroy Hxxx.
• You can deactivate the rule by disabling the user's account.
• We'd be comfortable introducing a "Can Create Herald Rules" application permission to limit rule creation to trusted users.

Probably none of these are great fits for your install, though. We've also contemplated adding a flag to make administrators truly omnipotent (e.g., allow them to see and edit everything), and could either do that or some more limited version of it, but haven't seen strong use cases for it yet.

How about this:

• We'll add a "Can Create Herald Rules" permission.
• We'll do a permission check every time we execute a personal rule, not just when one is created.
• If whitelisting users is reasonable, you can just create a "Trusted to Use Herald" group and you can add people who have earned access.
• If you don't want to whitelist users, you can just use the policy as a blacklist. Add users with problematic rules to the deny list, which will immediately deactivate their rules, then send them a message like "I disabled your access to Herald because you wrote a dumb rule, send me a nice apology note to get access back". This is administratively about the same as deleting the rule directly.

Seem reasonable?

In T6207#77543, @epriestley wrote:

Today:

• Users with access to the Phabricator host can destroy the rule with bin/remove destroy Hxxx.
• You can deactivate the rule by disabling the user's account.

Ok, this is good to know. If a user is misbehaving after being warned etc, disabling their account looks like a reasonable action.

• We'd be comfortable introducing a "Can Create Herald Rules" application permission to limit rule creation to trusted users.

Interesting, but you probably don't need to put time on this right now. If we need this, we can set the policy to a specific team, and add the users whitelisted there. I think the current Herald and policies plus the possibility of taking drastic actions should be enough.

I discussed the WMF situation in particular in more detail with @rush898 on IRC, and it looks like T6211 is a good path forward for the "security" case.

One thing I do think could help, and maybe I'm just being an idiot. If I create a global rule as an admin, and then a non-admin user creates a personal rule. On my test installs I see both rules as the non-admin if I go to http://fabapi.wmflabs.org/herald/query/all/ but only the global rule as the admin. That seems weird? I would expect to see the same rules in both cases.

It's expected that you can't see other users' personal rules. Administrators can't violate policies, and users' personal rules are private.

(There's some fuzziness with the ruleset right now; I believe you can see the effects of their rules in transcripts, for example. Herald predates policies and is generally awkward to balance cleanly against them. There are things we could do better, but I think the major interactions are working correctly today.)