Zwykli użytkownicy mogą czytać / etc / passwd, czy to dziura w zabezpieczeniach?

19

ls -l /etc/passwd

daje

$ ls -l /etc/passwd
-rw-r--r-- 1 root root 1862 2011-06-15 21:59 /etc/passwd

Tak więc zwykły użytkownik może odczytać plik. Czy to dziura w zabezpieczeniach?

— Ankur Agarwal
źródło

49

Rzeczywiste skróty haseł są przechowywane /etc/shadow, co nie jest czytelne dla zwykłych użytkowników. /etc/passwdprzechowuje inne informacje o identyfikatorach użytkowników i powłokach, które muszą być czytelne dla wszystkich użytkowników, aby system mógł działać.

— Michael
źródło

3

Nie bardzo - historycznie hasła były przechowywane w / etc / passwd - ale to sprawiło, że dopasowanie brutalnej siły stało się proste - stąd nowoczesne systemy wykorzystujące / etc / shadon z pam_unix i podobnymi.

— symcbean

4

Nowoczesne Linux używa /etc/shadow. Używają BSD /etc/master.passwd. Używa Solaris /etc/security/passwd. HP-UX używa, /.secure/etc/passwda lista jest długa ...

— Chris S

16

Zazwyczaj hashowane hasła są przechowywane w /etc/shadowwiększości systemów Linux:

-rw-r----- 1 root shadow 1349 2011-07-03 03:54 /etc/shadow

(Są one przechowywane w /etc/master.passwdsprawie systemów BSD ).

Programy, które muszą przeprowadzić uwierzytelnianie, nadal muszą działać z rootuprawnieniami:

-rwsr-xr-x 1 root root 42792 2011-02-14 14:13 /usr/bin/passwd

Jeśli nie podoba ci się setuid rootprogram i jeden plik zawierający wszystkie zaszyfrowane hasła w twoim systemie, możesz go zastąpić modułem Openwall TCB PAM . Zapewnia to każdemu użytkownikowi swój własny plik do przechowywania zaszyfrowanego hasła - w rezultacie liczba setuid rootprogramów w systemie może zostać drastycznie zmniejszona.

— Sarnold
źródło

13

Hasła nie były przechowywane /etc/passwdod lat; nazwa jest starsza, funkcja bycia lokalną bazą danych użytkowników pozostaje i w tym celu musi być czytelna dla wszystkich.

— geekozaur
źródło

2

światowa czytelność jest decyzją projektową, a nie koniecznością

— Ben Voigt

@Ben: więc uzasadnione jest, że nikt nie może zidentyfikować plików należących do kogoś innego? Obecnie jest to lokalny sklep dla NSS, nie dla PAM, pomimo swojej nazwy.

— geekozaur

1

Jest całkowicie możliwe, aby usługa uprzywilejowana wykonywała uid -> tłumaczenie nazw, bez umożliwienia nieuprzywilejowanym użytkownikom wyliczenia całej listy użytkowników. Niektóre systemy operacyjne wybierają tę opcję.

— Ben Voigt

1

@joechip Obecne systemy operacyjne nie mają na celu ukrycia użytkowników przed sobą. Wszystkich użytkowników można wyliczyć na wiele innych sposobów niż / etc / passwd. ls -la / home w systemie Linux, ls -la / Users w systemie MacOS X, reż C: \ Users w systemie Windows 7, ps -afux w systemach Unix. Zmiana wyboru projektu, o którym wspomniał Ben Voigt, po prostu utrudnia życie bez zmiany bezpieczeństwa.

— Magicianeer

1

@Magicianeer - Samo powiedzenie przykładu systemu Windows nie jest całkiem poprawne. Możesz pozyskać użytkowników innymi metodami, ale patrząc na folder C: \ users będzie tylko lista zalogowanych użytkowników; żaden użytkownik systemu.

— burnt_hand

6

W pewnym stopniu jest tak, ponieważ można zidentyfikować użytkowników. W przeszłości można było również odebrać ich hasła. Jednak jedynym identyfikatorem użytkownika, który naprawdę warto złamać, rootjest dobrze znany bez pliku hasła.

Na ogół użyteczność odczytu pliku haseł na świecie znacznie przewyższa ryzyko. Nawet jeśli nie byłoby to czytelne dla świata, działające getent passwdpolecenie unieważniłoby zysk bezpieczeństwa.

Zniknie zdolność użytkowników innych niż root do identyfikowania plików należących do innych osób. Możliwość identyfikacji posiadanych (użytkownika w pliku passwd) i nie posiadanych plików (użytkownika nie ma w pliku passwd) może być przydatna podczas przeglądania zawartości systemu plików. Chociaż byłoby to możliwe do rozwiązania za pomocą odpowiednich setuidprogramów, dodałoby to ogromny wektor ataku za pośrednictwem tych programów.

Ostatecznie jest to kwestia równowagi, a w tym przypadku powiedziałbym, że równowaga opiera się na czytelnym świecie haseł.

— BillThor
źródło