Protection & Security

an access-control model

Once the system knows who you are, it must decide what you may do — and there is more than one philosophy for making that decision. Think of three different buildings. In a shared apartment, whoever owns a room decides who else may enter it (the owner's discretion). In a military base, a central authority stamps clearances on people and classifications on documents, and no individual can override the rule that secret-cleared people may not read top-secret files. In a hospital, what you may access depends on your job title — any doctor on shift can read charts, any nurse can update vitals — regardless of who you personally are. These three philosophies are the access-control models: discretionary, mandatory, and role-based.

Discretionary access control (DAC) lets the owner of a resource decide who gets access, at their own discretion. Ordinary Unix and Windows file permissions are DAC: you own your files and you choose to share them, granting or revoking rights as you like. It is flexible and intuitive, but its weakness is exactly that discretion — a careless or tricked owner can leak data, and once you grant read access there is little stopping the recipient from copying the file onward. Mandatory access control (MAC) takes the decision out of the owner's hands: a system-wide policy, set by an administrator, governs all access according to labels (clearances and classifications), and not even the owner can relax it. MAC enforces rules like no read up, no write down to stop information flowing from high to low secrecy; it is rigid and harder to administer, but far stronger against insiders and tricked owners. Role-based access control (RBAC) assigns permissions to roles (like accountant or admin) and then assigns users to roles, so you manage a manageable handful of roles instead of permissions per person — the dominant model in large organizations because it scales and matches how real jobs are organized.

These models are not mutually exclusive — real systems layer them, and the right choice depends on the threat. DAC suits personal machines where convenience matters and the owner is trusted. MAC suits high-assurance settings (military, and systems hardened with SELinux or AppArmor) where you must contain even a compromised privileged process. RBAC suits scale and management. The honest caveat is that DAC's flexibility is also its danger: because owners can freely pass rights along, DAC cannot by itself stop confidential data from eventually leaking to someone unauthorized, which is precisely the gap MAC was invented to close.

On plain Linux (DAC), Alice runs chmod 644 report and may hand read access to anyone she likes. Add SELinux (MAC) and a policy can forbid the web server process from ever reading users' home directories — even if it is running as root and even if Alice's permissions would allow it. The system policy overrides the owner.

DAC obeys the owner; MAC's system policy overrides even the owner.

DAC's flexibility is also its limit: because an owner can freely pass rights along, DAC alone cannot stop confidential data from eventually reaching someone unauthorized — that flow-control gap is exactly why MAC exists.

Also called
DACMACRBACdiscretionary access controlmandatory access controlrole-based access control自由裁量存取控制強制存取控制角色存取控制