pam_exec environment data is not a safe secret channel

pam_exec runs an external command during a PAM module stage. It is available for authentication, account, password, and session processing. It also exports PAM items as environment variables and can expose the authentication token when configured to do so. Those features make it useful for integration and dangerous when the called program is not treated as privileged code.

The manual lists items such as PAM_RHOST, PAM_RUSER, PAM_SERVICE, and PAM_TTY among the exported environment. A helper may use them to decide how to log a login, notify a system, or apply a session policy. The values can still be influenced by the client or the service configuration. A script that parses them as shell fragments, uses them in a command line, or writes them to a world-readable log can create a new bug in an authentication path.

What pam_exec exposes

The expose_authtok option is especially sensitive. During authentication or password change, it exposes the authentication token to the called command. If the command is a shell script stored in a writable directory, launches another program through a relative path, or logs its arguments and environment, the credential can escape the intended PAM stack. Use it only with a small, administrator-owned program that has a clear reason to receive the token.

Execution identity and failure

The execution identity matters as well. PAM modules may run in a privileged context. seteuid can make the called program run with the authenticated user's effective UID, but that changes the security model and should be tested against the actual task. Do not assume that an option name alone proves the command cannot affect privileged state.

Deployment checklist

A deployment review should establish:

• Which PAM service invokes pam_exec.
• The exact command path and all of its arguments.
• Whether the command and every directory in its path are administrator-owned.
• Which PAM items the command consumes and how it quotes them.
• Whether authentication tokens are exposed.
• Where stdout, stderr, exit status, and failures are recorded.
• What happens when the helper is unavailable or returns an error.

Safe integration

The helper should use a fixed interpreter or direct executable, avoid shell interpolation of untrusted values, and write structured logs to a protected location. Treat environment variables as data, not as trusted configuration. If the command needs a secret, pass it through a purpose-built file descriptor or protected temporary file with a documented lifetime rather than relying on an environment block.

Test both success and failure paths. A missing helper, timeout, nonzero exit status, or malformed PAM item should not accidentally make authentication succeed when the stack expects failure. The PAM control flags decide that behavior, so review them with the helper rather than in isolation.

pam_exec is a sharp integration point because it sits close to login and can see authentication material. Use it only for a narrow, reviewed operation with a stable path and a safe error policy. The environment block is useful input for that operation, but it is not a protected secret store.

References

• Linux-PAM pam_exec manual: https://man7.org/linux/man-pages/man8/pam_exec.8.html