How do you design a D-Bus service with proper security policy isolation?

Designing a system-bus service securely means treating the D-Bus policy configuration as a real part of the service's attack surface, not an afterthought bolted on after the API is finished.

1. Default to deny. Ship a policy file under /usr/share/dbus-1/system.d/ that denies all method calls by default, then explicitly allow only the specific interfaces and methods that genuinely need to be callable, and by which users or groups.
2. Separate read-only and privileged operations onto distinct interfaces where practical, so a broad "allow read access" policy rule doesn't accidentally also grant access to a destructive or privileged method sharing the same interface.
3. Use PolicyKit for actions that need interactive authorization, such as a one-time root password or fingerprint prompt, rather than trying to encode that logic as a static D-Bus allow rule.
4. Run the service itself with the least privilege it needs, since D-Bus policy only controls who can call the service, not what the service itself is allowed to do once it's running as its own user or with its own capabilities.
5. Validate all method arguments defensively inside the service, since D-Bus policy controls who can call a method, not whether the arguments passed are sane, safe, or within expected bounds.