OT : Omezeni prihlasovani uzivatelu

[Pavel Kankovsky]

On Wed, 11 Oct 2000, Petr Novotny wrote:

Kdyz uz jsem ten flamewar nacal, tak to take dokoncim. :)

> Tohle neni pravda. Chybu lze opravdu vyloucit, at si programatorsky 
> folklor rika cokoliv - tedy chybu jinou nez chybu v navrhu.

Existuji nejmene dva faktory, ktere cini zaver, ze lze chybu na 100 %
vyloucit, ponekud pochybnym: (1) lidsky faktor, (2) princip neurcitosti.
Sam zminujete priklad, kde se muze uplatnit (1), tj. chyba primo v navrhu,
no rikejme radeji ve specifikaci, ale moznosti je daleko vic. Co se tyce
(2), tam pochopitelne muzete jako Einstein argumentovat, ze "Buh nehraje
v kostky", ale zatim to vypada, ze kvantova mechanika popisuje skutecne
chovani mikrosveta (kam se cim dal tim vice radi veskera elektronika).

> Ja to vidim takhle:
> Bud mam system, kde user space program si vede sva vlastni uid 

"Sva vlastni uid" je ne zcela srozumitelna kombinace pluralu a
singularu. Bud je to tak, ze pouziva jeden uid pro vsechny uzivatele (pak
plati nize popsane namitky), nebo ruzne uidy, a pak uziva bezpecnostnich
mechanismu jadra (proc by jinak pouzival ruzne uidy, ze?).

> a ma opravneni ke vsem schrankam. Je-li tento program bezpecny 
> (a vzhledem k jeho principialni jednoduchosti jde bezpecne udelat - 
> proste se po autentifuckaci uzivatele chrootne do jeho maildiru a 
> dal uz ma tak malo privilegii, ze neni co exploitovat), mam problem 
> vyresen,

Na vetsine unixu lze z chrootovaneho prostredi utect pres ptrace(),
bezi-li v systemu pod danym uzivatelem dalsi procesy. To se da omezit,
kdyz bude zaruceno, za kazdy z tech procesu bude mit "dumpable" na nule,
ale je to takove trochu nepresvedcive opatreni. Nebo lze ostatni procesy
aspon zabijet pomoci signalu, coz je sice z hlediska utocnika krajne
neproduktivni, ale muze to byt legrace. Byly navrhy, ze by takove syscally
mely brat v uvahu nastaveni korene fs, ale nemyslim, ze se to v historicky
kratke dobe stane standardni vlastnosti...uz jenom z toho duvodu, ze by
bylo mnohem systematictejsi poskytnout uplne jiny mechanismus na omezovani
pristupovych prav (mimochodem, nema nekdo nastudovano, jak funguje
jail() ve FreeBSD? ale capabilities jsou stejne nejlepsi :> ).

> Anebo mam system, kde se mi o uzivatele stara kernel a ja se 
> naopak staram, aby se uzivatele nemohli prihlasit jinak nez k 
> mailboxu.

Kernel zadne uzivatele neprihlasuje. To delaji nejaci demoni majici 
k tomu dostatecna opravneni. Chyba je v tom, ze si to kazdy z nich muze
delat, jak se mu zlibi. Kdyby museli (tj. nemohli by to nijak obejit) pro
prihlaseni uzivatele pouzivat jednotne nejakou systemovou komponentu,
nebyl by takovy problem nejakou jednotnou politiku dodrzovat.

(Mimochodem, polozme si otazku, co dela ne zcela duveryhodny demon
s rootovskymi pravy na stejnem systemu, kde je naprosto dokonale
bezpecny demon pro pristup k postovnim schrankam.)

> Obavam se, ze podle me interpretace :-) standardnich 
> bezpecnostnich pravidel je prvni pripad lepsi: Bezpecnostne-citlive 
> veci jsou soustredene na jednom miste a ne rozesete do milionu 
> interagujicich komponent. Audit lze provest mnohem snadneji.

Tak nevim, podle prvniho navrhu jsou "bezpecnostne-citlive" veci stejne
minimalne na dvou ruznych mistech: v kernelu (tam je to vzdycky) a v tom
user space programu. A v kazdem jsou implementovany uplne jinak, coz
znamena, ze kdyz budu treba chtit auditovat, co se v systemu deje, tak to 
nejspis budu muset delat dvema ci vice ruznymi zpusoby.

K tomu auditu: je celkem jedno, mam-li milion komponent nebo jednu, jejiz
objem je uhrnem uvedeneho milionum, protoze se v tom ani v jednom pripade 
nikdo nevyzna. Naopak mam-li neco v rozumne velikosti, pak rozdeleni na
komponenty s dobre definovanym rozhranim (zvlaste je-li nejakym zpusobem
a priori zaruceno, ze rozhrani nelze obejit) zpusobi, ze je mnohem snazsi
to udelat dobre (jak rikali uz za staroveku: rozdel a panuj).

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