OT : Omezeni prihlasovani uzivatelu

[Petr Novotny]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 14 Oct 2000, at 0:51, Pavel Kankovsky wrote:

> Existuji nejmene dva faktory, ktere cini zaver, ze lze chybu na 100 %
> vyloucit, ponekud pochybnym: (1) lidsky faktor,

Lidsky faktor nehraje roli. Nebo budete argumentovat, ze dukaz 
(treba) zakladni vety algebry je mozna spatne kvuli lidskemu 
faktoru?

> (2) princip neurcitosti.

Dtto. Pocitac pracuje nad konecnym poctem stavu, ne nad 
kontinuem.

> 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).

Dobre. Takze vy berete jako "realnou" (tj. ovazovani-hodnou) 
alternativu, ze sitovka se blbe koukne na kabel (z duvodu principu 
neurcitosti) a programu preda spravne rootovske username a heslo, 
ac se klient prihlasoval jako "pepa".

Tahle alternativa me nechava spat naprosto klidne. Stejne jako me 
nechava naprosto klidne spat alternativa, ze by najednou vsechen 
vzduch ze Zeme mohl protunelovat do Slunce a ja se udusil.

> > 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.

Omlouvam se; uid bylo mysleno jako podstatne jmeno pomnozne. 
Pokud chcete, vlozte tam "uids" nebo "u-i-decka".

> 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.

Znovu rikam: Utokum lze auditem "zabranit" (alespon se stejnou 
pravdepodobnosti, s jakou nekdo ukradne vas dopis postacce, 
nebo jej ona "omylem" preda nekomu, kdo vam je STRAAASNE 
podobny a ma falsifikat vasi obcanky). (Viz OpenBSD.) Cim min je 
system komplexni, tim lepe.

> Kernel zadne uzivatele neprihlasuje.

Omlouvam se, pouzil jsem v zapalu nevhodne slovo. Chtel jsem 
rict, kernel overuje pristup podle uid, ktere vede sam.

> Kdyby museli (tj. nemohli by to nijak obejit)
> pro prihlaseni uzivatele pouzivat jednotne nejakou systemovou
> komponentu, nebyl by takovy problem nejakou jednotnou politiku
> dodrzovat.

Aha. A kdyby byly vsechny systemy BSD, nebyl by problem s 
prenositelnosti kodu. A kdyby byly vsechny systemy MS-
Windows, nemusel byste se bezpecnostni strankou vubec 
zaobirat. "What's your point?"

> (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.)

Mam jen omezene prostredky, abych provedl audit. Muzu 
prohlednout nektere programy, ale ne vsechny. Schvalne, kdo z 
vas prohlizel (treba) drivery sitovky, zda tam nejsou nejake 
problemy?

> > 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.

No dobre. Rizeni pristupu v kernelu muze byt dosti jednoduche ("jsi 
root, nejsi root"), pokud nezacne vadit, ze "chvili jsi root byl, tak 
jsem ted zmaten". :-)

> 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.

No a?

> 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.

Pokud zavedete uzivatele do systemu, komponent, na nez musite 
davat pozor, pribyva: ftp, ssh, login, telnet, pripadne kombinace 
techto programu a upload/tvoreni souboru jako ~/.ssh/rc... Takze 
vase poznamka je sice spravna, ale v nami resenem pripade je 
irrelevantni. :-)

> 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).

Mate nejaky dobre definovany (a overeny, kdyz uz rovnou ne 
auditovany) mechanismus, jak rict, ze "uzivatel pepa smi pop3, 
nesmi imap, pres ftp smi uploadovat jen do podadresare 
public_html, pres ssh se smi prihlasit ale nesmi editovat .procmail? 
Myslim tim jiny, nez nezapomenout editovat tisic konfiguraku? :-) 
Jinak receno, nakolik je tohle reseni zavisle na "lidskem faktoru"?

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.2 -- QDPGP 2.61a
Comment: http://community.wow.net/grt/qdpgp.html

iQA/AwUBOeqra1MwP8g7qbw/EQJZswCeIZJuv1dXNs+3GuAMPtkYoHlx7mQAoNWL
izyIIY8rhCrMItRBHHg2JMEm
=sLCs
-----END PGP SIGNATURE-----
--
Petr Novotny, ANTEK CS
Petr.Novotny na antek.cz
http://www.antek.cz
PGP key ID: 0x3BA9BC3F
-- Don't you know there ain't no devil there's just God when he's drunk.
                                                             [Tom Waits]