Konfigurace SELinuxu (TeX)

[Pavel Kankovsky]

On Tue, 19 Dec 2006, Jan Kasprzak wrote:

> - jak rict "ted prekladam neduveryhodny zdroj"? Pomoci nove role?
> 	Pomoci specialniho uzivatele?  Pomoci nejakeho typu/domeny?
> - jak oznacit soubory? mit zvlast typ/domenu pro adresar s docasnymi
> 	soubory, zvlast pro spustitelne veci TeXu a zvlast pro ostatni
> 	veci TeXu? Nebo typ/domena je spatne slovo a mam pouzit roli?
> 
> 	Z ruznych dokumentaci vicemene rozumim zakladnim pojmum,
> ale uz ne tomu, jak tyto vlastnosti pouzit (a ktere pouzit), abych
> dosahl vyse uvedeneho.

Pár opožděných poznámek víceméně teoretického charakteru:

SELinux ve mne budí dojem, že byl navržen pro lidi, kteří už dávno mají
informační toky, type enforcement a podobné věci v malíčku a denně to
používají v práci (rozuměj v NSA <g>) a chtěli by to mít i doma na Linuxu.  
Navíc se to snažili udělat strašně obecné a výsledek je poněkud
překombinovaný. A že ho tato predeterminace stále dost ovlivňuje (ale
možná je nevyhnutelné v tom smyslu, že bez apriorní znalosti problematiky
(a je to dost velká věda, tedy nechci Yenyu podceňovat, ale z dokumentace 
SELinuxu nebo čehokoli podobného se tohle asi fakt naučit nedá (*)) nelze 
dost dobře navrhnout smysluplnou bezpečnostní politiku).


Tohle vypadá jako víceméně klasický problém na omezení toku infomací,
zejména nahlíženo z pohledu integrity (viz Bibův model), čili role bych
do toho netahal.

"Nedůvěryhodný zdroj" by měl být vyjádřen tak, že vstupní soubor bude mít
typ signalizující nízký stupeň (**) integrity. Pokud ho nějaký subjekt
(třeba onen TeX) bude chtít, bude muset přejít do domény (***) pro tento
nízký stupeň integrity, odkud bude moci zapisovat zase jen do objektů
určitých typů se stejně nízkou (nebo ještě nižší) integritou, což bude
například ten adresář pro dočasné soubory a soubory v něm.

Omezovat přístup pro čtení není v jistém smyslu potřeba, když se správně
omezí zápis (+), jelikož jakákoli důvěrná data bude možna přemístit
pouze do povoleného výstupního souboru. Pokud by to nedostačovalo (např.
je v plánu výstupní soubory publikovat, což by vyžadovalo jejich
"deklasifikaci"), pak je to duální problém, tentokrát s důvěrností:
soubory, které lze číst nebo kam lze zapisovat, budou mít typ s nízkým
stupněm důvěrnosti, ostatní budou mít vysoký stupeň. Doména, ve které bude
zpracovatel fungovat, bude muset mít také nízký stupeň, aby mohla
zapisovat, čili bude schopna číst jen vybrané soubory s patřičným typem.


(*) I když je pravda, že třeba dnes již klasický článek "The Inevitability 
of Failure: The Flawed Assumption of Security in Modern Computing 
Environments" je svým způsobem do dokumentace SELinuxu zahrnutý a že 
hlubokou meditací nad tímto článkem lze dosáhnout základní úrovně 
osvícení. :)

(**) Samozřejmě to nutně neznamená, že v systému musí být nějaká globální
lineární hierarchie.

(***) Type enforcement použitý v SELinuxu považuje domény za typy (což má
hlubší smysl, jelikož v počítači jsou subjekty zároveň objekty), ale pro
větší názornost budu u klasifikace subjektů používat termín doména.

(+) Pojem zápis samozřejmě zahrnuje i odeslání dat nějakým komunikačním
kanálem. Ostatně ani nechceme, aby nedůvěryhodný vstupní soubor během
svého zpracování mohl exploitnout nějakou díru a pak například rozesílat
spam, takže je smysluplné to zablokovat.


--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."