ftp, rc-inetd, tcpserver

[Grzegorz Stanislawski]

On Mon, 18 Oct 1999, Tomasz Kłoczko wrote:

> On Sun, 17 Oct 1999, Grzegorz Stanislawski wrote:
> [..]
> > Jeszcze jedna kwestia: "W kazdej rzeczy miary patrzaj."
> > Do kazdego bardziej zaawansowanego systemu autoryzacji (obojetnie czy to
> > kerberos, ldap czy radius) admin musi dojzec/dorosnac i podjac suwerenna
> > decyzje czy jest mu to potrzebne.

> A i owszem masz rację .. "W kazdej rzeczy miary patrzaj.".
> Zmuszanie każdego do tego, żeby sam ręcznie przenosił bazę użytkowników do
> LDAP (choć i za pomocą MigrationTools) czy też sam po dodaniu w systemie
> wsparcie do LDAP w postaci modułu NSS do LDAP żeby zmodyfikował
> nsswitch.conf czy też w następnym etapie po dodaniu pam_ldap żeby sam
> ręcznie zmodyfikował wszystkie pliki w /etc/pam.d to jest poprostu
> przesada .. i to nawet na potrzeby tych co dobrze wiedzą co robią. To tak

Oczywiscie. Jak pisalem, nikomu nie bedzie sie chcialo pisac z lapd.conf
dn= 2k razy. Migration tools sa jak najbardziej potrzebne. Warunek: musza
wykonywac jasne operacjie konwersji dajace sie opisac jednym zdaniem:
"pwconv - przenosi hasla z /etc/passwd do /etc/shadow dzieki czemu beda
one ukryte przed uzytkownikami."

> w shadow. Z PAM jest o tyle źle, że w zasadzie taka modyfikacja nie byłaby
> wogóle potrzebna o ile poprawnie funkcjonowałby i byłby nadal rozwijany
> pam_pwdb, gdyz to ten moduł miał załatwiać zunifikowany interfejs do
> rożnych typów baz potrzebnych przy autentykacji. Gdyby nie to, to operacje
> konieczne do wykonania przejścia np. na LDAP byłyby znacznie prostrze.
> 
Kiedys bardzo mi sie podobal pwdb, ale teraz mysle ze bobrze ze nie jest
rozwijany, poniewaz nie dodawal swoim istnieniem nic poza paroma
zmarnowanymi taktami procesora i balaganem (choc mozy bylo by inaczej
gdyby byl skonczony). Konfiguracja bazy danych z ktorej autoeyzowani bylu
userzy rozkladala sie pomiedzy a /etc/nssswitch do /etc/pwdb.conf. PAM
sobie (pwdb.conf) a glibc sobie (nssswitch) jakims rozwiazaniem do tego
byl nsspwdb.so ale trzeba sie bylo postarac zeby go zdobyc i zainstalowac.
Wracajac do PAMa. I tak nie uda sie uciec przed reczna konfiguracja
pam.d/*. Bo skad, obojetnie jak inteligentny, skrypt ma wiedziec jaka
polityke bezpieczenstwa przyjmie admin w stosunku do takich aplikacji jak
chfn,chsh, rlogin, xauth czy zwyklego ftp albo nawet telneta.
Skladnie pam.conf i tak kazdy pozadny admin musi znac.
W tym kontekscie dodanie do pama autentykacji z ldapa to "trivial task".
Spesjalnie zwracam uwage ze chodzi o autentykacje, od autoryzacji
pozostaje nssswitch, ktorego tez trzeba skonfigurowac.
Wielu z was nie wie tak naprawde do czego sluzy i co potrafi pam.

> We wszelkiej automatyzacji chodzi nie tyle o wspomaganie osadzania np.
> pakietu w środowisku co bardziej o odseparowanie w pewiem dobrze
> wytestowany podprogram (moze być i w sh) który wykona _tylko_ to co
> konieczne i w stu procentach powtarzalne przy okazji jakieś operacji np.
> przejścia na trzymanie niektórych baz w LDAP.
> 
Zgadzam sie. Tymniemniej decyzja wyboru bazy z ktorej bedzie dokonywana
autoryzacja powinna byc podjeta przez admina, co powinien on potwierdzic
reczna zmiana w odpowiednich plikach konfiguracyjnych.

> Reszta zgodzę się, że może być i najprawdopodobniej będzie przesadą. Takim
> wykroczeniem do pewnego stopnia mogłoby się wydawać przeciw tej zasadzie
> jest to co sie dzieje w rc-inetd, niemniej tutaj poprostu mam nadzieję, że
> tworząc coś takiego tworzy się nie inna co lepszą jakość .. wogóle. Co
> samo w sobie usprawiedliwia taki krok (IMHO). Radziłbym zwróciś uwagę na

Rowniez sie zgadzam. Choc widze dla tego inne wytlumaczenie.
Chodzi o to czeby utworzyc iniwersalna forme opisu serwisow, tak aby
niezaleznie od stosowanego inetd wszystko ladnie dzialalo.
To samo stlo sie w rc-scriptsach - dawniej izywalismy ifconfig, teraz
iproute a opis interfejsow pozostal ten sam.

> Co powiesz na takie podejście Grasiek ?
> 
Podsumowujac.
Zaden program instlacyjny czy sktypt nie moze wyreczyc admia w opracowaniu
i wdrozeniu polityki bezpieczenstwa. Musi to zrobic sam, a skrypty moga mu
jedynie pomoc w jej realizacji. IMHO jedyna pomoca na ktora tutaj moze
liczyc admin to konwersja baz czy pomoc w zakladaniu kont (jeden skrypt
adduser ktory bedzie zaipsywal dane tam gdzie trzeba. moze dalo by sie
to zrobic za pomoca jakis pluginow). Proponowal bym sie skupic nad tym
ostatnim.
Troche jest IMHO bez sensu ze ta dyskusja wyplynela przy okazji rc-inetd,
ale lepiej niz wcale.


> kloczek 
> -- 
Grzegorz Stanslawski
Open-Net / PKFL