Більшу частину часу при встановленні програми з джерела рекомендується створити нового користувача та нову групу та надати /usr/local/<myapp>нещодавно створені користувачі та групи права власності.
Чому така угода вважається хорошою практикою?
Що це покращує?
Приклад: користувач mysql / група mysql для сервера баз даних MySQL.
Відповіді:
Практика полягає не у створенні одного користувача та групи за програмою, а за послугою. Тобто програми, які виконуються місцевим користувачем, не потрібно встановлювати як користувач, крім root. Це демони , програми, що працюють у фоновому режимі, і які виконують запити, що надходять через мережу або інші засоби зв'язку, які повинні працювати як виділений користувач.
Демон працює як призначений користувач, так що, якщо він поводиться недоброзичливо (через помилку, ймовірно, викликану зловмисником), шкода, яку він може зробити, обмежена: зачіпаються лише файли даних демона (якщо тільки зловмиснику не вдалося знайти локальну кореневу дірку , що може статися). Наприклад, демон бази даних mysqldпрацює як виділений користувач і група, mysql:mysqlа файли даних бази даних ( /var/lib/mysql/*) належать mysql:mysql.
Зверніть увагу, що виконувані демони та інші статичні файли даних та конфігурації, які використовуються, але не повинні бути змінені демоном, не повинні належати спеціальному користувачеві; їм належить root:root, як і більшість програмних та конфігураційних файлів. У mysqldпроцесі немає перезапису бізнесу /usr/sbin/mysqldабо /etc/mysql/my.cnf, таким чином, ці файли не повинні належати mysqlкористувачеві або бути написаними mysqlкористувачем або mysqlгрупою. Якщо деякі файли потрібно читати тільки демоном та адміністратором, вони повинні належати користувачу root та виділеній групі та мати режим 0640 ( rw-r-----).
Спеціальна категорія виконуваних файлів, яка не може бути власником, root:root- це програми, на які користувач викликає, але потребують виконання додаткових привілеїв. Ці виконувані файли повинні бути УИП коренем , якщо вони повинні працювати (по крайней мере, частково) в якості кореня; тоді виконуваний файл повинен мати режим 4755 ( rwsr-xr-x). Якщо програма потребує додаткових привілеїв, але не як корінь, то програму слід зробити жорсткою, щоб додаткові привілеї надходили через групу, а не через користувача. Тоді виконуваний файл має режим 2755 ( rwxr-sr-x). Причини двоякі:
Причина, яку вважають хорошою практикою, полягає в тому, щоб не допустити, щоб інші користувачі системи перекривали дані та конфігураційні файли для конкретної програми.
В якості прикладу mysql/ mysqlбути власником сховища для файлів баз даних mysql заважає комусь, що не використовує API програми, пошкодити бази даних. Плюс у користувача mysqlзазвичай немає справжньої оболонки, тому ніхто також не може ввійти як цей користувач.
/usr/bin/atналежить daemon/daemonUbuntu
atце не демон. Він налаштований daemonтак, що він може спілкуватися з atdдемоном через приватні файли.
Створення нової групи / користувача для нового встановленого демона покращує безпеку. Коли серверний процес запускається під таким користувачем, він обмежений правами доступу цього користувача. Для порівняння: коли він запускається як root, він може зробити все.
Ця різниця важлива у випадку, якщо ваш демон неправильно налаштований та / або містить помилку, пов’язану із безпекою.
Я не впевнений, що ви маєте на увазі під другою частиною вашого питання, тобто з частиною /usr/localвласності. Взагалі немає сенсу, що той самий користувач, Xпід яким працює демон з міркувань безпеки, також володіє каталогом із бінарними файлами (адже в такому випадку він може змінити їх у випадку експлуатації). Але каталог з файлами даних, на якому працює демон, повинен бути доступний X- найпростіший спосіб налаштувати це - зробити Xвласником каталогів / файлів даних.
Запуск демон під власним спеціальним користувачем - це лише одна техніка захисту, інші включають певну «хронізацію» або використання системи обов'язкового контролю доступу (MAC) (наприклад, SELinux).
Це питання безпеки. Це обмежує шкоду, яку може зробити той, хто ввірветься в демон-заявку. Користувацькі програми зазвичай належать стандартному користувальницькому користувачеві, наприклад root.
Якщо ваш веб-сервер, поштовий сервер та база даних працюють як один і той же користувач, це полегшує їх компроміс. Якщо будь-який з них має помилку або неправильну конфігурацію, яка дозволяє отримати доступ до системи, цей доступ може бути використаний для доступу до всіх трьох програм.
Якщо всі вони мають окремі облікові записи, як це рекомендовано, ймовірно, буде доступний лише компрометований додаток. Хоча відомості про іншу конфігурацію іншого можуть бути прочитані, навряд чи можна внести зміни.
Багато демонів дозволяють користувачам завантажувати та завантажувати файли і в іншому випадку робити те, що не хотілося б, щоб вони могли робити з конфігураціями для інших демонів. Якщо у кожної програми є власний користувальницький і груповий спосіб, захистити демони простіше.
Наявність групи, що відповідає демону, спрощує надання безпечного доступу демону до файлів і каталогів. Якщо файл або каталог належить іншому користувачеві, але належить до групи демонів, він, як правило, буде доступний лише для читання. Дозволи доступу можна легко перевірити та виправити за допомогою таких інструментів, як find.