Least Privilege, Explained

Authority should follow responsibility

A component should own only the resources its declared job requires.

A keyboard-facing layer may need access to input reports and buffers, but that does not make it the owner of a storage controller, a display surface, or every device handle in the machine. Least privilege names that boundary: memory, interrupts, queues, and interfaces stay with the component responsible for them.

The principle applies to layers

Different driver layers can need different authority.

A class layer can provide shared behavior while a function driver handles device-specific registers, and a filter can observe one part of that exchange without owning the whole stack. A user-mode service may coordinate policy through a defined interface rather than receiving direct control of hardware resources. The exact split follows the device model.

Narrow scope supports review

A clearly declared surface gives reviewers something concrete to examine.

Package metadata, interface documentation, and lifecycle records can identify which component opens a queue, maps a buffer, receives an interrupt, or releases a handle. Those details turn a broad question about “driver access” into a set of ownership statements tied to a keyboard, disk, camera, or other device function.

Least privilege is not a guarantee

Least privilege is a design principle, not an outcome certificate.

Reducing unnecessary authority can limit the reach of an unexpected state, but it does not prove that an implementation is free of defects or that every interface is trustworthy. A careful reference describes the boundary, the resource, and the reason for access without promising a particular security result.

Questions and answers