Звичайні користувачі вміють читати / 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. Solaris використовує /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

світ читабельність - це дизайнерське рішення, а не необхідність

— Бен Войгт

@Ben: тому розумно, що ніхто не може ідентифікувати файли, які належать комусь іншому? Сьогодні це місцевий магазин для NSS, а не PAM, незважаючи на його назву.

— geekosaur

1

Цілком можливо, щоб привілейований сервіс здійснював переклад імен uid ->, не дозволяючи непривілейованим користувачам перераховувати весь список користувачів. Деякі ОС вибирають цю опцію.

— Ben Voigt

1

Поточні ОС @joechip не призначені для приховування користувачів один від одного. Усі користувачі можуть бути перераховані набагато більше способів, ніж / etc / passwd. ls -la / home на Linux, ls -la / Користувачі на MacOS X, dir C: \ Користувачі в Windows 7, ps -afux в системах Unix. Зміна вибору дизайну, на яку Бен Войгт натякав, просто ускладнює життя без зміни безпеки.

— Magicianeer

1

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

— burnt_hand

6

Певною мірою це так, як ви можете ідентифікувати користувачів. Раніше ви також можете забрати їх паролі. Однак єдиний користувальницький номер, який дійсно варто зламати, - це те, rootщо добре відомо без файлу пароля.

Корисність того, щоб читати файл файлів паролів, як правило, значно перевищує ризик. Навіть якби він не був читаний у всьому світі, функціонуюча getent passwdкоманда призведе до втрати безпеки.

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

Зрештою, це питання балансу, і в цьому випадку я б сказав, що баланс твердо налаштований на читати світ паролів.

— BillThor
джерело