Які ідеальні дозволи Unix для звичайних каталогів веб-проектів?


12

Які ідеальні мінімальні дозволи в восьмеричному форматі для подальших подань у веб-додатку?

  1. Каталог, де користувач завантажив статичні файли (файли images / swf / js)
  2. Каталог, де адміністратор завантажив статичні файли (файли images / swf / js), буде розміщений
  3. Каталог, де знаходяться бібліотеки, які використовуються в додатку
  4. Каталог, в якому розміщатимуться виконувані / доступні скрипти на стороні сервера
  5. Каталог, де вже наявні файли (txt або xml) будуть редагуватися кодом на стороні сервера

Ось мої пропозиції та виправдання

  1. 555, кожен може читати і писати, ніхто не може виконати
  2. 544, власник може писати один, всі інші вміють лише читати, ніхто не може виконати
  3. 000, нікому не потрібно читати, писати і не виконувати, буде використовуватися тільки веб-сервер?
  4. 661, власник може читати, писати, всі інші можуть лише виконувати
  5. 600, власник може читати, писати (можливо, не потрібно), ніхто більше нічого не може зробити

Зараз мене цікавлять дві речі:

  1. Чи є щось, що зазвичай використовується в веб-додатках, що я пропустив у першому списку?
  2. Чи є з чим ви не згодні у другому списку, яка ваша альтернатива, і чому це краще?

1
Я не розумію, чому люди НЕ використовують ACL в наші дні ...
pfo

Відповіді:


20

Припускаючи, що "веб-додаток" працює на сервері (наприклад, apache, nginx тощо) і написаний якоюсь динамічною мовою сценаріїв (наприклад, PHP, Ruby тощо), ви нерозумієте, хто такий "користувач".

Користувач не є людиною, яка увійшла у вашу програму - це, і їх роль у програмі (адміністратор тощо) абсолютно не має значення для сценарію. Користувач - це користувач системи Linux, під яким працює процес. Код вашого веб-сайту виконується лише одним користувачем - він може бути користувачем вашого веб-сервера (що насправді не дуже добре), або він може бути специфічним для вашого сайту (що набагато краще).

У Linux Linux користувачі належать до груп - ми можемо додати користувача до іншої групи та призначити привілеї цій групі.

Хороша настройка дозволить вашому серверу працювати як один користувач (назвемо цього користувача «веб-сервер»), а ваш динамічний сценарій мови (наприклад, через FastCGI) як власний користувач (один користувач на сайті - давайте назвемо першого користувача «site1») .

Щоб обслуговувати ваші файли, веб-серверу потрібен доступ до них, а мова сценарію потребує доступу до них. Це означає: 'site1' та 'webserver' повинні мати можливість читати ваші файли. Тільки одна з них, однак, може "володіти" файлами. Власник - це «користувач» (у користувачі, групі, іншому). Нам також потрібна наша мова сценаріїв, щоб мати можливість записувати в каталог (і читати файли, написані ним). Отже, користувачеві 'site1' потрібні дозволи читання та запису. Оскільки ми хочемо, щоб групові та інші дозволи були максимально обмежуючими, нашим "власником" буде "site1", а відповідні дозволи користувачів будуть прочитані та записані.

Оскільки ми не можемо вказати дозволи для нашого веб-сервера як іншого "користувача", ми додамо "веб-сервер" до групи "site1" (можна, звичайно, створити іншу групу з "site1" і "webserver" у ній. Все) членам цієї групи будуть надані однакові дозволи. Найбільш розслаблені дозволи (користувача, групи, іншого набору) будуть застосовані до будь-якого користувача для визначення їх дозволів.

Варто відзначити, що для гарної установки не потрібно, щоб файли мали дозволи на виконання динамічної мови. Файли не запускаються безпосередньо, а скоріше читаються в інтерпретаторі - для запуску типового сценарію (той, що нічого не пише) потрібні лише дозволи на читання.

Дозвіл 'Execute' на каталоги має інше значення - він дозволяє пройти, не маючи можливості читати вміст. Для того, щоб мати можливість читати файл у каталозі, користувач повинен мати дозволи "виконати" у ВСІМ каталозі над ним.

Для веб-програми кожен файл повинен мати дозволи на читання власника, інакше це досить безглуздий файл. Незалежно від того, чи користувач або адміністратор завантажує файли (через веб-додаток), "власнику" (тобто динамічній мові) потрібні дозволи на запис. Ефективна установка намагатиметься подавати статичні файли безпосередньо через веб-сервер, оскільки динамічні мови мають тенденцію повільно читати великі файли та повторювати вміст. Тому веб-серверу потрібен доступ для читання до ваших статичних файлів.

Тому мінімальні права доступу до файлів можуть бути:

  • Файл у каталозі, де користувач завантажив статичні файли (файли images / swf / js), міститиме: 640
  • Файл у каталозі, куди адміністратор завантажив статичні файли (файли images / swf / js), міститиме: 640
  • Файл у каталозі, де знаходяться бібліотеки, які використовуються у програмі: 400 (або 440)
  • Файл у каталозі, де розміщуються виконувані / переглядаються скрипти на стороні сервера: 400 (або 440)
  • Файл у каталозі, де вже наявні файли (txt або xml) будуть редаговані за кодом на стороні сервера: 640 або 600
    • (залежить від того, чи буде відображатись веб-сервер, не змінений часом)

Незважаючи на те, що мінімальні права доступу до каталогу можуть бути:

  • Каталог, де користувач завантажив статичні файли (файли images / swf / js), міститиме: 750
  • Каталог, де адміністратор завантажив статичні файли (файли images / swf / js), розміщуватиметься: 750
  • Каталог, де перебувають бібліотеки, які використовуються в додатку: 500 (або 550) [має бути не менше 510]
  • Каталог, де розміщуватимуться виконувані / проглядаються серверні скрипти: 500 (або 550) [має бути не менше 510]
  • Каталог, де вже наявні файли (txt або xml) будуть редаговані за кодом на стороні сервера: 750 або 700
    • (залежить від того, чи буде веб-сервер подавати файли звідси, не змінені часом)

Ще раз - ваш веб-сервер повинен мати "виконувати" дозволи на кожен каталог вище того, до якого йому потрібен доступ, - тому навіть якщо веб-сервер не обслуговуватиме файли з заданої директорії, ми повинні надати йому виконання дозволів.

Досить поширеним є надання веб-серверу читання доступу до більшості файлів (тому змініть ці 500 на 550). За дозволом "дещо захищені" дозволи зазвичай 755 для каталогів і 644 для файлів - не мають дозволів на виконання, кожен може читати, і лише користувач може писати - ви зауважите, що переважна більшість файлів у системі Linux мають ці права.

Майте на увазі, що "інші" дозволи стосуються будь-якого користувача системи, який не є власником або в групі (тобто всіх інших користувачів системи). Зберігати ваші "інші" дозволи обмежувально добре, оскільки ці користувачі невідомі - ви прямо не давали їм дозволу. Іншими дозволами часто найпростіше скористатись компрометованою системою (наприклад, одна з причин, чому / tmp є загальною ціллю).

У контексті вищесказаного я не думаю, що ваші останні два запитання є такими актуальними. Встановіть права доступу до каталогу на 550 (а для файлів - 440), а потім надайте користувачеві дозволи на запис для будь-яких каталогів, до яких буде писати ваша програма (тобто каталог: 750; файл: 640).

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


@Iain: Абсолютно - думав про дозвіл файлів у той момент - це виправить - спасибі.
cyberx86

1

Для виконання роботи нормально мати мінімальний набір дозволів. Якщо у вас є веб-сервер і користувачі мають спільну групу, ви можете усунути необхідність доступу до нього o. Дозволи також стосуються користувачів. Здається, ви неправильно зрозуміли восьмеричні дозволи.

  1. 555 - r-xr-xr-xні rw-rw-rw. Оскільки це каталог, то для створення / видалення файлів потрібно xвстановити, щоб 750 rwxr-x---було б хорошим місцем для початку. Це дозволяє користувачеві, якому належить каталог, додавати / видаляти файли та всім членам загальної групи отримати доступ до них.
  2. Те саме, що і 1. вище.
  3. Якщо вони справді статичні файли, то 050 дозволить веб-серверу отримати доступ, однак для створення файлів в першу чергу 750 було б мінімальним.
  4. Те саме, що 3 вище.
  5. 070 було б мінімальним, щоб веб-сервер міг читати та змінювати файли, але файли потрібно створити, тому 770, ймовірно, більш реалістичний.

Чи не потрібно веб-серверу виконувати дозволи в каталозі для читання файлів (точки №1 (740?), 3, 5)?
cyberx86

До! дійсно x потрібен для доступу до файлів r просто дозволяє перелічити їх ... амблі вимкнено для отримання більше кави.
користувач9517

0

Як правило, можна використовувати режим 0755, 0775 або 2775 для каталогів (біт SGID в каталогах, для BSD і Linux, якщо файлова система встановлена ​​з BSD семантикою, приведе групове об'єднання нових файлів у відповідність до налаштувань батьківського каталогу, а не GID за замовчуванням творця файлу). Це дозволяє всім користувачам переходити (chdir в і через) та читати (виконувати команду ls або виконувати системні виклики readdir / read), про які йдеться. Альтернативи додають параметри групи / запису і, як зазначалося, біт SGID у каталогах, можуть допомогти зберегти всі файли та підкаталоги, пов'язані з відповідною групою.

Для файлів, як правило, використовується 0644 або, можливо, 0664 (читається у всьому світі та з груповим записом чи ні). Очевидно, що для скриптів та бінарних файлів CGI слід додати x-біт; а для деяких спеціальних ситуацій із надзвичайно добре перевіреними бінарними файлами можна додати біти SUID або SGID. Зазвичай UNIX та Linux ігнорують біт SUID / SGID у скриптах і лише шанують його семантику для власних зібраних, виконуваних бінарних файлів. Однак ви можете запускати свій сайт під чимось на зразок Apache з деяким модулем на зразок "setuidhack", який може бути використаний для того, щоб веб-сервер шанував біти SUID / SGID навіть на інтерпретованих сценаріях. (Це робиться статтером демона HTTP () з кожним файлом та використанням власного спеціального коду fork () / execve (), інтерполіруючи правильний рядок інтерпретатора у вектор execve (), а не просто передаючи виконуваний файл '

Це лише найзагальніші вказівки. Вони не "ідеальні" для будь-яких ситуацій, і ви обов'язково повинні проконсультуватися з документами для вашого веб-сервера та будь-якого веб-додатку чи рамок, які ви встановлюєте та налаштовуєте ... і, ймовірно, ви хочете проконсультуватися з експертом з безпеки UNIX перед вами відкрийте будь-який із своїх файлів, кодів або серверів у загальнодоступному Інтернеті.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.