{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"cs/permission","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/cs/permission/","da":"https://cmaintz.github.io/tech-atlas/da/terms/cs/permission/"},"term":{"en":"Permission","da":"Rettighed"},"aka":{"en":["access right","privilege"],"da":["adgangsrettighed","tilladelse"]},"domain":["cs"],"cluster":"os","layer":"os","status":"current","summary":{"en":"A specific right given to an account, such as to read, change or delete a file, or to run a program.","da":"En bestemt ret, som en konto får, fx til at læse, ændre eller slette en fil eller til at køre et program."},"body":{"formal":{"en":"A rule, kept by the operating system or an application, stating which account may perform which action on which thing. Anything not granted is refused.","da":"En regel, som styresystemet eller et program holder styr på, og som angiver, hvilken konto der må udføre hvilken handling på hvad. Alt, der ikke udtrykkeligt er givet lov til, bliver afvist."},"plain":{"en":"Like the keys on a caretaker's ring - each key opens particular doors, and the key to the boiler room does not open the office.","da":"Som nøglerne på en viceværts nøglering - hver nøgle åbner bestemte døre, og nøglen til fyrrummet åbner ikke kontoret."},"inPractice":{"en":"At an accounting firm, a student assistant's account may read the client folders but not change them, while a partner's account may do both. The difference is simply two different permissions.","da":"I et revisionsfirma må en studentermedhjælpers konto læse kundemapperne, men ikke ændre dem, mens en partners konto må begge dele. Forskellen er blot to forskellige rettigheder."},"whyItMatters":{"en":"Permissions decide how far a mistake or a stolen login can reach; too many of them turn a small incident into a large one.","da":"Rettigheder afgør, hvor langt en fejl eller et stjålet login kan række; for mange af dem gør en lille hændelse til en stor."}},"deepDive":{"en":"Formally, permissions are entries in Lampson's access matrix (1971): subjects as rows, objects as columns, rights in the cells. Real systems store the matrix sparsely, either by column as access control lists attached to objects, or by row as capabilities held by subjects. Unix and Windows are ACL-based for files; file descriptors and Windows handles behave like capabilities once obtained, since rights are checked at open time and cached in the handle.\n\nClassic Unix permissions are 12 mode bits: read, write and execute for owner, group and others, plus setuid (4000), setgid (2000) and the sticky bit (1000). Directory semantics differ from files: r lists names, x allows traversal, and w on a directory allows creating and deleting entries regardless of the files' own permissions, which is why world-writable directories like /tmp need the sticky bit (mode 1777). The umask (commonly 022 or 027) removes bits from newly created files. POSIX ACLs add named users and groups with a mask entry, and Linux capabilities split root's power into units such as CAP_NET_BIND_SERVICE, CAP_SYS_ADMIN and CAP_DAC_OVERRIDE, so a program can hold only what it needs. Setuid-root binaries remain a steady source of local privilege escalation because any bug in them runs with full rights.\n\nWindows associates each securable object with a security descriptor containing an owner SID and a discretionary ACL of access control entries. The access check compares the ACEs with the SIDs in the caller's access token, evaluating them in order; canonical ordering puts explicit deny before explicit allow before inherited entries, and an object with a NULL DACL grants everyone full access while an empty DACL grants no one anything. Inheritance propagates ACEs down folder trees. For network shares the effective access is the more restrictive of share and NTFS permissions. Separately, user rights (privileges) such as SeDebugPrivilege, SeBackupPrivilege and SeImpersonatePrivilege bypass object ACLs entirely; the last is behind the \"Potato\" family of escalations from service accounts to SYSTEM. Mandatory integrity levels (Low, Medium, High, System) add a no-write-up rule on top of the DACL.\n\nDiscretionary access control lets owners grant rights at will; mandatory access control (SELinux, AppArmor, Windows integrity levels) enforces a system policy that owners cannot override. Higher-level models such as RBAC and ABAC (NIST SP 800-162) decide which permissions an account should have, but they are ultimately enforced as low-level permissions like these. The operational problems are privilege creep, where people accumulate rights across role changes, over-broad grants such as Everyone or Authenticated Users on shares, and permissions that are never reviewed. ISO/IEC 27001:2022 addresses this in Annex A 5.15 (access control), 5.18 (access rights) and 8.2 (privileged access rights), and least privilege, together with periodic access reviews, remains the governing principle.","da":"Formelt er rettigheder felter i Lampsons adgangsmatrix (1971): subjekter som rækker, objekter som kolonner og rettigheder i cellerne. Virkelige systemer lagrer matricen spredt, enten pr. kolonne som adgangskontrollister (ACL'er) knyttet til objekterne eller pr. række som capabilities, subjekterne har. Unix og Windows er ACL-baserede for filer; fildeskriptorer og Windows-handles opfører sig som capabilities, når de først er udstedt, fordi rettighederne tjekkes ved åbning og gemmes i handlet.\n\nKlassiske Unix-rettigheder er 12 mode-bits: læse, skrive og udføre for ejer, gruppe og andre plus setuid (4000), setgid (2000) og sticky bit (1000). For mapper er betydningen en anden end for filer: r giver lov at liste navne, x at gå igennem, og w på en mappe giver lov at oprette og slette poster uanset filernes egne rettigheder, og derfor skal mapper, alle kan skrive i, som /tmp, have sticky bit (mode 1777). Umask (typisk 022 eller 027) fjerner bits fra nyoprettede filer. POSIX-ACL'er tilføjer navngivne brugere og grupper med en mask-post, og Linux capabilities deler roots magt op i enheder som CAP_NET_BIND_SERVICE, CAP_SYS_ADMIN og CAP_DAC_OVERRIDE, så et program kun har det, det har brug for. Setuid-root-programmer er fortsat en stabil kilde til lokal rettighedseskalering, fordi enhver fejl i dem kører med fulde rettigheder.\n\nWindows knytter hvert sikringsbart objekt til en security descriptor med en ejer-SID og en discretionary ACL af access control entries (ACE'er). Adgangstjekket sammenligner ACE'erne med SID'erne i kalderens access token og evaluerer dem i rækkefølge; den kanoniske orden sætter eksplicitte afvisninger før eksplicitte tilladelser før nedarvede poster, og et objekt med en NULL-DACL giver alle fuld adgang, mens en tom DACL ikke giver nogen noget. Nedarvning spreder ACE'er ned gennem mappetræer. For netværksshares er den effektive adgang den mest restriktive af share- og NTFS-rettighederne. Derudover omgår brugerrettigheder (privilegier) som SeDebugPrivilege, SeBackupPrivilege og SeImpersonatePrivilege objekternes ACL'er helt; den sidste ligger bag \"Potato\"-familien af eskaleringer fra tjenestekonti til SYSTEM. Obligatoriske integritetsniveauer (Low, Medium, High, System) lægger en regel om ingen skrivning opad oven på DACL'en.\n\nDiskretionær adgangskontrol lader ejere tildele rettigheder efter eget valg; obligatorisk adgangskontrol (SELinux, AppArmor, Windows' integritetsniveauer) håndhæver en systempolitik, som ejere ikke kan tilsidesætte. Modeller på højere niveau som RBAC og ABAC (NIST SP 800-162) afgør, hvilke rettigheder en konto bør have, men de håndhæves i sidste ende som rettigheder på lavt niveau som disse. De driftsmæssige problemer er rettighedsophobning, hvor medarbejdere samler rettigheder op gennem rolleskift, for brede tildelinger som Everyone eller Authenticated Users på shares, og rettigheder, der aldrig bliver gennemgået. ISO/IEC 27001:2022 behandler det i Annex A 5.15 (adgangsstyring), 5.18 (adgangsrettigheder) og 8.2 (privilegerede adgangsrettigheder), og mindste privilegium kombineret med periodiske gennemgange af adgange er fortsat det styrende princip."},"edges":[{"type":"requires","to":"cs/account","confidence":"high","strength":"normal"},{"type":"part-of","to":"cs/access-control","confidence":"high","strength":"normal"},{"type":"used-with","to":"cs/process","why":{"en":"Every process carries the permissions of the account it runs as.","da":"Hver proces bærer rettighederne fra den konto, den kører som."},"confidence":"high","strength":"normal"}],"depth":1,"sources":[{"title":"Operating Systems: Three Easy Pieces","url":"https://pages.cs.wisc.edu/~remzi/OSTEP/","tier":"textbook","publisher":"Arpaci-Dusseau"},{"title":"NIST SP 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations","url":"https://doi.org/10.6028/NIST.SP.800-162","tier":"standard","publisher":"NIST"}],"draft":true}