Обычные пользователи могут читать / etc / passwd, это дыра в безопасности?


19
ls -l /etc/passwd

дает

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

Таким образом, обычный пользователь может прочитать файл. Это дыра в безопасности?

Ответы:


49

В нем хранятся реальные хэши паролей /etc/shadow, которые не читаются обычными пользователями. /etc/passwdсодержит другую информацию о пользовательских идентификаторах и оболочках, которые должны быть доступны для чтения всем пользователям, чтобы система могла функционировать.


3
Не совсем - исторически пароли хранились в / etc / passwd - но это делало прямое сопоставление грубой силы - следовательно, современные системы используют / etc / shadon с pam_unix и тому подобное.
symcbean

4
Современный Linux использует /etc/shadow. Использование BSD /etc/master.passwd. Солярис использует /etc/security/passwd. HP-UX использует, /.secure/etc/passwdи этот список можно продолжить ...
Chris S

16

Обычно хешированные пароли хранятся в /etc/shadowбольшинстве систем Linux:

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

(Они хранятся в /etc/master.passwdна системах BSD ) .

Программы, которые должны выполнить аутентификацию, все еще должны работать с rootпривилегиями:

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

Если вам не нравятся setuid rootпрограммы и один единственный файл, содержащий все хешированные пароли в вашей системе, вы можете заменить его модулем PAM Openwall TCB . Это предоставляет каждому пользователю свой собственный файл для хранения своего хешированного пароля - в результате количество setuid rootпрограмм в системе может быть значительно сокращено.


13

Пароли не были сохранены в /etc/passwdтечение многих лет; имя унаследовано, функция локальной базы данных пользователя остается, и она должна быть доступна для чтения всем для этой цели.


2
удобочитаемость мира - это дизайнерское решение, а не необходимость
Бен Фойгт

@ Бен: так разумно, что никто не может идентифицировать файлы, которые принадлежат кому-то еще? В наши дни это местный магазин для NSS, а не для PAM, несмотря на его название.
geekosaur

1
Полностью возможно, чтобы привилегированная служба выполняла uid -> перевод имени, не позволяя непривилегированным пользователям перечислять весь список пользователей. Некоторые ОС выбирают эту опцию.
Бен Фойгт

1
@joechip Текущие ОС не предназначены для сокрытия пользователей друг от друга. Все пользователи могут быть перечислены по-разному, чем / etc / passwd. ls -la / home в Linux, ls -la / Users в MacOS X, dir C: \ Users в windows 7, ps -afux в системах Unix. Изменение выбора дизайна, на которое ссылается Бен Фойгт, просто усложняет жизнь без изменения безопасности.
Чародей

1
@Magicianeer - просто сказать, что пример Windows не совсем правильно. Вы можете получить пользователей с помощью других методов, но при просмотре папки C: \ users будут перечислены только те пользователи, которые вошли в систему; не любые пользователи системы.
burnt_hand

6

В некоторой степени это так, как вы можете идентифицировать пользователей. В прошлом вы также могли подобрать их пароли. Однако действительно стоит взломать один идентификатор пользователя, rootкоторый хорошо известен без файла паролей.

Полезность того, чтобы файл паролей читался как мир, обычно намного перевешивает риск. Даже если бы она не была доступна для чтения во всем мире, действующая getent passwdкоманда сделала бы усиление безопасности недействительным.

Возможность для пользователей без полномочий root идентифицировать файлы, принадлежащие другим, исчезнет. Возможность идентифицировать собственные (пользователь в файле passwd) и неизвестные файлы (пользователь не в файле passwd) может быть полезна при просмотре содержимого файловой системы. Хотя можно было бы решить эту проблему с помощью соответствующих setuidпрограмм, это добавило бы огромный вектор атаки через эти программы.

В конце концов, это вопрос баланса, и в этом случае я бы сказал, что баланс заключается в том, чтобы мир паролей читался.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.