Czy dostęp do /etc/passwd jest ok?

[qrees 0]

Wybacz, przez 10 sekund udalo mi się wyciągnąć 'jedynie' jeden z glownych plikow systemowych... Ehh... Obyś się kiedyś nie zdziwił... ;-)

jakbyś kiedyś korzystał z Linuxa to byś wiedział, że do tego pliku musi mieć dostęp każdy użytkownik bo inaczej nie będzie miał możliwości zalogowania się do systemu.

[T 6]

jakbyś kiedyś korzystał z Linuxa to byś wiedział, że do tego pliku musi mieć dostęp każdy użytkownik bo inaczej nie będzie miał możliwości zalogowania się do systemu.

To akurat nie jest do końca prawda (w każdym razie wcale nie musi mieć możliwości wylistowania go z poziomu shella, php etc.). Aczkolwiek zgadzam się, że prawa odczytu dla /etc/passwd nie są luką w bezpieczeństwie.

[qrees 0]

To akurat nie jest do końca prawda (w każdym razie wcale nie musi mieć możliwości wylistowania go z poziomu shella, php etc.). Aczkolwiek zgadzam się, że prawa odczytu dla /etc/passwd nie są luką w bezpieczeństwie.

Owszem, można np uruchomić php w safe mode, albo w jail'u, ale to już są dość radykalne rozwiązania.

[MasterNETpl 100]

Wszyscy piszą o użytkownikach systemowych, otwarty dostęp do /etc/passwd oraz /etc/shadow przykładowo z poziomu php, a co to za problem stworzyć wirtualny system którego użytkownicy nie będą siedzieć w passwd i shadow a co za tym idzie dostęp do tych plików będzie zbędny?

Tylko tu oczywiście wchodzą rozwiązania własne z wykluczeniem ogólno znanych gotowych paneli administracyjnych.

[T 6]

Wszyscy piszą o użytkownikach systemowych, otwarty dostęp do /etc/passwd oraz /etc/shadow przykładowo z poziomu php, a co to za problem stworzyć wirtualny system którego użytkownicy nie będą siedzieć w passwd i shadow a co za tym idzie dostęp do tych plików będzie zbędny?

Mylisz. Jakkolwiek +r dla /etc/passwd nie jest luką w bezpieczeństwie, to do /etc/shadow już jak najbardziej tak, bo właśnie tam znajdują się hashe haseł. /etc/shadow stworzono właśnie w celu ukrycia tych hashy.

 

Tylko tu oczywiście wchodzą rozwiązania własne z wykluczeniem ogólno znanych gotowych paneli administracyjnych.

Jestem zwolennikiem autorskich rozwiązań, ale powiem szczerze, że nie widzę sensu tworzenia osobnego systemu autentyfikacji przy tym zastosowaniu (może oprócz samej poczty w niektórych zastosowaniach). Dzięki temu stracilibyśmy dostęp do mnóstwa dobrych narzedzi operujących na uid/gid.

[pleple 0]

Mylisz. Jakkolwiek +r dla /etc/passwd nie jest luką w bezpieczeństwie, to do /etc/shadow już jak najbardziej tak, bo właśnie tam znajdują się hashe haseł. /etc/shadow stworzono właśnie w celu ukrycia tych hashy.

Ja przyznaję rację Adrianowi ponieważ on mówił o sytuacji kiedy w plikach passwd i shadow po prostu nie ma użytkowników (albo są ale tacy bez haseł, bez shella itp). Wtedy dostęp do tych plików rzeczywiście nic nie zmienia. Nie chodzi więc o dostęp do samego pliku tylko o to jakie informacje się w nim znajdują..

[T 6]

Ja przyznaję rację Adrianowi ponieważ on mówił o sytuacji kiedy w plikach passwd i shadow po prostu nie ma użytkowników (albo są ale tacy bez haseł, bez shella itp). Wtedy dostęp do tych plików rzeczywiście nic nie zmienia. Nie chodzi więc o dostęp do samego pliku tylko o to jakie informacje się w nim znajdują.

Chodzi o to, że wymienił jednym tchem passwd i shadow, a to zupełnie inna historia. Nawet gdyby w shadow nie znajdowało się w danej chwili pół hasha, to nie należy go z zasady udostępniać użytkownikom do odczytu.

[pleple 0]

Chodzi o to, że wymienił jednym tchem passwd i shadow, a to zupełnie inna historia. Nawet gdyby w shadow nie znajdowało się w danej chwili pół hasha, to nie należy go z zasady udostępniać użytkownikom do odczytu.

A możesz uzasadnić czemu ? Bo ja na prawdę nie rozumiem o co Ci chodzi...

[T 6]

A możesz uzasadnić czemu ? Bo ja na prawdę nie rozumiem o co Ci chodzi...

Eh, dyskusja była o passwd, a Adrian dołączył do niej shadow tak jakby było to to samo. Tymczasem nie jest, bo właśnie w shadow zazwyczaj znajdują się hashe haseł. Nawet jeśli konta klienckie będą autentyfikowane w inny sposób, to np. root może miec ustawione hasło. Ponadto shadow domyślnie nie jest dostępny do odczytu, więc obecność shadowa z +r dla wszystkich w systemie świadczyłoby zapewne o tym, że admin zrobił to przypadkiem. I wreszcie jeśli decydowalibyśmy się na stworzenie własnego systemu autentyfikacji użytkowników to tymbardziej należałoby zamknąć ich w chroocie, bo nie byłoby już chyba żadnego powodu, dla którego należałoby tego nie robić.

[pleple 0]

No tak, wszystko spoko tylko wcale nie wyjaśniasz czemu posiadanie +r na /etc/shadow jest złe. Jeśli nie ujawniasz w ten sposób żadnych informacji to nie niesie to ze sobą żadnych negatywnych konsekwencji. Jakby się uprzeć to można nawet użyć tego jako takiej przynęty - wsadzić tam trochę hashy różnych haseł, w tym najważniejsze - roota. Niech sobie ludzie ściągają i zużywają prąd na rozkodowanie, byle nie na naszej maszynie... Jeśli odhashują hasło to tylko się zdziwią, że i tak nie działa i okaże się, że zmarnowali wiele czasu niepotrzebnie (bo na przykład hasła i tak trzymane są w bazie danych a nie w /etc/shadow). Nie twierdzę, że faktycznie warto tak robić (mi by się nie chciało a poza tym jak się jest jakimś usługodawcą to zaraz na forum będą latać komentarze jakie to dzieci system konfigurowały..) ale staram się tylko pokazać, że nie ma w tym nic złego (podkreślę ostatni raz - o ile nie ma tam haseł, tylko z tym Twoim stwierdzeniem polemizuję).

 

P.S. Przepraszam za OT.. mam nadzieję, że ktoś to wydzieli..

[MasterNETpl 100]

Chodzi o to, że wymienił jednym tchem passwd i shadow, a to zupełnie inna historia. Nawet gdyby w shadow nie znajdowało się w danej chwili pół hasha, to nie należy go z zasady udostępniać użytkownikom do odczytu.

Sądziłem, że wiadome jest iż passwd i shadow to dwie zupełnie inne bajki.

 

"Hakerzy" którzy uważają, iż dzięki passwd zdobędą dostęp do wszystkiego to chyba tacy którzy naczytali się "faq'ów" z przed kilku lat.

 

Zresztą czy na prawdę trudno jest zrozumieć, iż z passwd wyczytać można jedynie lokalizację katalogu usera oraz przypisaną powłokę która i tak nie musi być prawdą?

 

Eh, dyskusja była o passwd, a Adrian dołączył do niej shadow tak jakby było to to samo.

Sądziłem, że osoby znając się na administracji będą wiedziały, że nie jest to to samo ale chyba widocznie będę musiał pisać wszystko dokładnie z każdym objaśnieniem

 

Tymczasem nie jest, bo właśnie w shadow zazwyczaj znajdują się hashe haseł. Nawet jeśli konta klienckie będą autentyfikowane w inny sposób, to np. root może miec ustawione hasło.

Nigdy haseł kont Klientów nie zapisuje w shadow (oddzielny system wirtualny do którego user nie dotrze )

 

I wreszcie jeśli decydowalibyśmy się na stworzenie własnego systemu autentyfikacji użytkowników to tymbardziej należałoby zamknąć ich w chroocie, bo nie byłoby już chyba żadnego powodu, dla którego należałoby tego nie robić.

Wcale nie trzeba zamykać userów w chroocie by stosować własny system autentyfikacji userów

 

Jestem zwolennikiem autorskich rozwiązań, ale powiem szczerze, że nie widzę sensu tworzenia osobnego systemu autentyfikacji przy tym zastosowaniu

Każdy robi to co lubi

 

bo na przykład hasła i tak trzymane są w bazie danych a nie w /etc/shadow

Łakomy kąsek

 

zaraz na forum będą latać komentarze jakie to dzieci system konfigurowały..

Tia... a w środku ich postów czytamy... "nie znam się..."

 

PS. niech MOD wydzieli - porozmawiamy sobie w innym temacie.

[pleple 0]

Łakomy kąsek

Heh a czemu? Baza danych to nie zawsze *SQL do którego dostęp ma każdy znający hasło i port, na którym nasłuchuje DBMS

[MasterNETpl 100]

@pleple po prostu mając dostęp do obcych serwerów nie spotkałem się jeszcze aby była to baza danych (serwer) do której zwykli użytkownicy nie mieli dostępu

[pleple 0]

Ja się spotkałem. Baza SQL nasłuchująca tylko na sockecie (ale nie przez TCP), dostępnym tylko dla roota no i znajdującym się poza chrootem użytkowników. Innym podejściem może być użycie jakiejś bazy danych w formacie berkley-DB czy ostatecznie nawet jakiegoś zupełnie własnego rozwiązania z autorskim modułem NSS (jak ktoś jest lekko szalony )