Securing Power Manager

The Scheduler is a computer wide process. This means it can run a schedule even when no-one is logged in. It also means the Scheduler has significant power and control over the computer.

Power Manager trusts administrator users.

The Scheduler needs to know if the user is an administrator. Administrators have the right to modify and control the Scheduler; everyone else may only view parts of the Scheduler.

Historically¹, Power Manager delegated to Pluggable Authentication Modules (PAM) to make this determination. This approach worked and was secure but required asking the user for their credentials.

Any time credentials need to be entered is a poor user experience. Each entry has risks of user interface intimidation and security fatigue. Power Manager moved away from this approach as soon as was practicable.

Power Manager prefers passive authentication, where no interaction is required by the user. To achieve this Power Manager needs a trusted secure means of determining the user’s identity.

There is nothing special or novel about the approach being taken. These information is shared to help you better understand how Power Manager works and the steps we take to protect you.

Establishing Trust

Being an administrator is determined by the user’s membership of the admin group. If the user is a member of the admin group, then they are an administrator and can control the Scheduler.

Trust is established through UNIX domain socket peer credentials.

There are additional complications with sandboxing and limited access to common locations for UNIX domain sockets. Putting aside these complications, below are the core steps that allow Power Manager to establish authenticated local connections without requiring users to enter their credentials:

1. Power Manager publishes a notary service as a UNIX domain socket at a known secure path;
2. Clients connect to the notary service and confirm the notary’s peer credentials are of an elevated user and group, i.e. root and wheel;
3. Clients send the notary a request containing a Certificate Signing Request (CSR);
4. The notary uses the client’s peer credentials to determine the client’s identity;
5. The notary signs the CSR using a session scoped local Certificate Authority (CA). The signed certificate is associated with the client’s identity;
6. The notary returns the client’s signed certificate, service details, and the public certificate used by Power Manager’s Scheduler for Transport Layer Security (TLS);

The exchange above provides the notary with an opportunity to evaluate the client’s identity, and for the client to securely obtain the Scheduler’s service certificate.

With certificates securely exchanged, communication between Power Manager’s Scheduler and clients is encrypted by Transport Layer Security (TLS) and authenticated with Mutual Transport Layer Security (mTLS).

At no point have credentials, secrets, or private keys been exchanged. The use of a well established Public Key Infrastructure (PKI) approach means authentication has been achieved passively and securely.