Princip nejnižších privilegií

Princip nejnižších privilegií je široce uznávaný způsob ochrany dat a funkčnosti před nebezpečnými chybami aplikací a nezasvěceným správcováním.

Princip nejnižších privilegií též známe jako princip nejnižší autority (Principle of least authority - POLA).

Jádro operačního systému obyčejně pracuje s maximálním oprávněním, protože je srdcem operačního systému a má přístup k hardwaru. Jednou ze základních povinností operačního systému, obzvlášť víceuživatelských, je správa a řízení dostupnosti hardwaru a požadavky na přístup k němu od běžících procesů. Pokud jádro havaruje, mechanismy, kterými je stav udržovaný havarují s ním. Přestože pro CPU existuje možnost obnovení bez potřeby studeného resetu, kód, který pokračuje ve vykonávaní, není vždy optimální. Bezpečnost je sice stále prosazovaná, ale operační systém nedokáže vhodně reagovat na pády, protože je nedokáže detekovat. Důvodem je, že jádro se buď zastavilo, nebo počítadlo programu pokračovalo ve vykonávaní programu v nekonečném a obyčejně nefunkčním cyklu.

Pokud po havárii pokračuje vykonávání načítáním a spuštěním kódu trojského koně, autor škodlivého kódu se může zmocnit řízení veškerých procesů. Princip nejnižších privilegií nutí kód běžet s nejnižším stupněm oprávnění, takže v tomto případě — nebo v situaci, kdy vykonávání pokračuje z neočekávané lokality — vykonávaný kód nemá možnost napáchat větší škody. Jedna z metod používaných na dosažení tohoto efektu může být implementována přímo v hardwaru mikroprocesoru. V architektuře x86 výrobce navrhl čtyři (ring 0 - ring 3) „módy“. (Tento výraz může být matoucí, protože termín "mód" je v některých operačních systémech uváděn v souvislosti s množinou bitů spojující se s daným prostředkem).

Termín „nejnižší privilegium“ bývá často nepochopen a občas nesprávně zaměněn s konceptem TCSEC - zmenšení důvěryhodné výpočetní báze (TCB). Zmenšení je daleko přísnějším požadavkem, který je použitelný jen pro funkčně silnější zajišťovací třídy, konkrétně B3 a A1

Nejnižší privilegium bývá často spojované s metodou zvanou privilege bracketing, což je přijetí nevyhnutelných privilegií v nejbližším možném momentě a jejich zrušení okamžitě po tom, co nejsou nezbytně nutná - to pomáhá vyhnout se dopadům vyplývajícím z chybného kódu, který neúmyslně využívá větší privilegia než jaká skutečně potřebuje. Nejnižší privilegium bývá též interpretované v souvislosti s distribucí DAC práv. Příkladem je uplatnění toho, že umožnění přístupu na čtení a zápis do souboru F uživateli U porušuje princip nejnižšího privilegia, pokud U stačí na dokončení své úlohy pouze právo na čtení souboru F.

V některých operačních systémech můžeme narazit na implementaci, ve které se procesy vykonávají s množinou potenciálních a množinou aktivních privilegií. Samotné množiny privilegií se dědí od rodiče, o čemž rozhoduje sémantika fork(). Spustitelný soubor vykonávající privilegovanou funkci může být označen množinou oprávnění, logickým rozšířením pojmů set user ID a set group ID. Dědění souborových privilegií procesem je určené sémantikou skupiny systémových volaní exec(). Přesný způsob, kterým potenciální a aktuální privilegia procesů a souborová privilegia vzájemně interagují, může být složitý. Prakticky, princip nejnižšího privilegia je vykonávaný přinucením procesu běžet pouze s oprávněními vyžadovanými vykonávanou úlohou. Dodržování tohoto modelu je poměrně složité a náchylné na chyby.

Nejstarším historickým případem nejnižšího privilegia je pravděpodobně zdrojový kód login.c, který začíná vykonávání s právy superuživatele (root) a ve chvíli, kdy už je nepotřebuje, odebírá jejich pomocnou setuid() s nenulovým argumentem.

• Lepší stabilita systému. Pokud kódu omezíme možnosti změn, které může v systému vykonat, bude jednodušší testovat jeho možné akce a interakce s ostatními aplikacemi. Lze tedy zajistit, aby aplikace neměla možnost vykonávat operace, jež by vedly ke zhroucení systému nebo nepříznivě ovlivnily ostatní aplikace v tomto systému spuštěné.

• Vyšší bezpečnost systému. Pokud kód omezíme v systémových akcích, jež může vykonávat, nelze zneužít zranitelnosti jedné aplikace k ovládnutí zbytku systému. Např. Microsoft tvrdí, že "práce ve standardním uživatelském režimu poskytuje zákazníkovi zvýšenou ochranu proti neúmyslnému poškození na úrovni systému způsobenému "shatter útoky" a malwarem, stejně tak root kity, spywarem a nedetekovatelnými viry”.

• Zjednodušení nasazení aplikací (deployment). Všeobecně čím nižší privilegia aplikace požaduje, tím jednodušeji se aplikace nasazuje ve větším prostředí. To je obvykle důsledkem prvních dvou výhod. Aplikace, které instalují ovladače zařízení nebo vyžadují zvýšená bezpečnostní privilegia, mají obvykle ve svém nasazení zahrnuté dodatečné kroky (např. ve Windows řešení bez ovladačů zařízení může být spustitelné bez jakékoliv instalace, takže ovladače zařízení musí být instalovány samostatně s použitím instalační služby windows za účelem udělení zvýšených oprávnění ovladačů.

Podle Jamesa Whittakera není v praxi skutečně nejnižší privilegium definovatelné a taktéž není možné ho dosáhnout.[3] Neexistuje žádný způsob, jak vyhodnotit nejnižší počet privilegií, které bude proces kdy potřebovat na vykonání svých funkcí. Je totiž nemožné zjistit všechny hodnoty proměnných, které zpracuje, všechny adresy, které bude potřebovat, přesný čas vykonávání atd.Nejlepším praktickým řešením je omezení privilegií tak, aby se eliminovala ta, u kterých předpokládáme, že nebudou nikdy potřebná. Toto řešení se však ukazuje jako velmi odlišné od minimální množiny privilegií. Takovéto omezení podstatně snižuje efektivitu provedení nejnižšího privilegia.

Podle Matta Bishopa je dalším omezením nespojitost kontroly, kterou má operační prostředí (bezpečný operační systém) nad privilegii pro jednotlivé procesy.[4] V reálné praxi je téměř nemožné řídit přístup procesu k paměti, čas běhu procesu, adresy vstupních a výstupních zařízení nebo módy s přesností potřebnou na eliminaci přesné množiny privilegií, která bude proces nezbytně potřebovat. To poněkud redukuje použitelnost tohoto principu.

Původní formulace pochází od Saltzera a Schroedera:

Každý program a každý uživatel systému by měl pracovat s použitím nejmenší množiny privilegií potřebných na dokončení práce. (Ochrana informací v počítačových systémech, 1974)

Peter J. Denning se tomu ve svém článku "Operační systémy tolerantní vůči chybám" věnoval v širší perspektivě při popisu 4 základních principů tolerance vůči chybám.

Dynamické přiřazování privilegií bylo ještě dříve popsáno Rogerem Needhamem v roce 1972.[5][6]

• Počítačová bezpečnost
• Princip nezbytné znalosti (need-to-know)

• Ben Mankin, The Formalisation of Protection Systems, Ph. D thesis, University of Bath, 2004
• P. J. Denning. Fault tolerant operating systems. ACM Computing Surveys. 1976, s. 359–389. Dostupné online. DOI 10.1145/356678.356680. ISSN 0360-0300. (anglicky)Je zde použita šablona {{Cite journal}} označená jako k „pouze dočasnému použití“.
• Jerry H. Saltzer, Mike D. Schroeder. The protection of information in computer systems. Proceedings of the IEEE. September 1975, s. 1278–1308. Dostupné online. DOI 10.1109/PROC.1975.9939. (anglicky)Je zde použita šablona {{Cite journal}} označená jako k „pouze dočasnému použití“.
• DEITEL, Harvey M. An introduction to operating systems. revisited first. vyd. [s.l.]: Addison-Wesley Dostupné online. ISBN 0-201-14502-2. S. 673. (anglicky)Je zde použita šablona {{Cite book}} označená jako k „pouze dočasnému použití“. page 31.

V tomto článku byl použit překlad textu z článku Principle of least privilege na anglické Wikipedii.

• The Saltzer and Schroeder paper cited in the references.
• NSA (the one that implemented SELinux) talks about the principle of least privilege
• A discussion of the implementation of the principle of least privilege in Solaris
• "Proof that LUA makes you safer" by Dana Epp
• Applying the Principle of Least Privilege to User Accounts on Windows XP, by Microsoft
• Privilege Bracketing in the Solaris 10 Operating System, Sun Microsystems^{[nedostupný zdroj]}