Обмежте користувача Linux лише власними файлами

Уявіть собі налаштування сервера спільної веб-хостингової компанії, де декілька (~ 100) клієнтів мають оболонку доступу до одного сервера.

Багато веб-програмного забезпечення рекомендує chmod файли 0777 . Я нервую, що наші клієнти нерозумно стежать за цими навчальними посібниками, відкриваючи їх файли для інших наших клієнтів. (Я, звичайно, сам не користуюся cmod 0777!) Чи існує спосіб переконатися, що клієнти можуть отримувати доступ лише до власних файлів і не дозволяти їм отримувати доступ до файлів, доступних для читання у світі, від інших користувачів?

Я переглянув AppArmor , але це дуже щільно пов'язане з процесом, який, здається, не працює в цьому середовищі.

Поставте обмежений та незмінний каталог між зовнішнім світом та захищеними файлами, наприклад

/
 ├─ bin
 ├─ home
 │  └─ joe <===== restricted and immutable
 │     └─ joe <== regular home directory

або /home/joe/restricted/public_html.

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

Незмінність може бути зроблена за допомогою chattr +iабо шляхом зміни власності на щось подібне root:joe.

Самий простий спосіб для створення цієї ієрархії на Ubuntu буде редагувати /etc/adduser.confі набір GROUPHOMESдо yes.

Є варіант, який ви можете розглянути (залежно від того, скільки роботи ви хочете зробити для цього).

Як вже публікували інші, "зазвичай" ви не можете перешкодити комусь із доступом до оболонки читати файли, доступні для читання у світі.

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

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

Це було багато накладних витрат, це було безладдя, і кожен раз, коли я щось оновлював, він ламався.

Але сьогодні я думаю, що ви можете досягти цього досить легко за допомогою опції chroot OpenSSH :

WikiBooks OpenSSH

Я виявив, що списки контролю доступу POSIX дозволяють вам, як адміністратору системи, захищати своїх користувачів від найгіршого їхнього власного невігластва, переосмислюючи звичайний дозвіл на файлову систему-групу користувачів, без особливого шансу зламати щось вирішальне. .

Вони можуть бути особливо корисними, якщо вам, наприклад, потрібні домашні каталоги, щоб бути доступними у всьому світі, оскільки веб-вміст повинен бути доступним для апачу в ~/public_html/. (Хоча з ACL тепер ви можете робити і зворотний, видалити доступ для всіх і використовувати специфічний ефективний ACL для користувача apache.)

Так, знаючий користувач може їх видалити / змінити знову, просто нечасто, що це малоймовірно, а ті користувачі, які, як правило, не є зручними для chmod -R 777 ~/будь-якого, чи не так?

Вам потрібно змонтувати файлову систему за допомогою aclпараметра монтажу:

 mount -o remount,acl /home

У багатьох дистрибутивах за замовчуванням створюються групи користувачів, кожен користувач має свою первинну групу, і я встановив усіх користувачів у вторинній групі з немисленою назвою users.

Використовуючи ACL, тепер тривіально запобігати доступу інших користувачів до домашніх каталогів:

Перед:

 chmod 0777 /home/user* 

 ls -l /home/user*
 drwxrwxrwx.  2 user1  user1  4096 Jul 11 15:40 user1
 drwxrwxrwx.  2 user2  user2  4096 Jul 11 15:24 user2

Тепер встановіть ефективні дозволи каталогів для членів usersгрупи 0без читання, запису чи доступу:

 setfacl setfacl -m g:users:0 /home/user*

 ls -l 
 drwxrwxrwx+  2 user1  user1  4096 Jul 11 15:40 user1
 drwxrwxrwx+  2 user2  user2  4096 Jul 11 15:24 user2

+Знак означає наявність налаштувань ACL там. І getfaclможе підтвердити, що:

getfacl /home/user1
getfacl: Removing leading '/' from absolute path names
# file: home/user1
# owner: user1
# group: user1
user::rwx
group::rwx
group:users:---
mask::rwx
other::rwx

group:users:---Показують , що група ефективно , не мають права доступу, незважаючи на регулярні дозволу на інобуттяother::rwx

І тестування як user1:

[user1@access ~]$ ls -la /home/user2
ls: cannot open directory /home/user2: Permission denied

Другим загальним рішенням для спільних систем є автоматизатор монтувати домашні каталоги на вимогу на сервері, призначеному для доступу до оболонки. Це далеко не дурне доказ, але зазвичай лише кілька користувачів будуть реєструватися одночасно, тобто лише домашні каталоги цих користувачів видимі та доступні.

Linux Containers (LXC) може бути найкращою комбінацією chroot та окремої системи.

1. Вони більше схожі на просунутий chroot, а не на віртуалізацію, але ви могли поєднувати різні операційні системи на одному сервері.

2. Ви можете надати користувачеві повну операційну систему та закріпити його там, тож коли користувач увійде, він переходить до свого контейнера. Ви також можете обмежити використання процесора та пам'яті.

У Стефана Грабера, автора LXC, є чудовий підручник, який допоможе вам розпочати роботу.

Наприклад, якщо ви хочете, щоб користувач мав доступ лише до власної homeдиректорії, вам слід зробити:

cd /home
sudo chmod 700 *

Тепер /home/usernameвидно лише його власнику. Щоб зробити це за замовчуванням для всіх нових користувачів, редагувати /etc/adduser.confі набору DIR_MODEдо 0700замість 0755замовчування.

Звичайно, якщо ви хочете змінити типовий DIR_MODE, це залежить від вашого розповсюдження, той, про який я розмістив, працює Ubuntu.

редагувати

Як правильно сказано в @Dani_l , ця відповідь є правильною, оскільки вони НЕ читають у світі.

Просто бути педантичним - Ні, немає.
@Marek дав правильну відповідь , але ваше запитання неправильне - ви не можете перешкодити нікому отримати доступ до файлів, "читаних у всьому світі".
Або вони читаються у всьому світі, або їх немає. @ Відповідь Марека правильна в тому, щоб зробити їх НЕ читатими у всьому світі.

Я не бачу жодної згадки про "обмежений оболонку" у відповідях, наданих до цього часу.

ln / bin / bash / bin / rbash

Встановіть це як оболонку для входу.

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

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

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

Створіть групу, що містить цих двох користувачів. Тепер створіть каталог із цією групою та коренем користувача. Цей каталог повинен мати дозволи 750, що означає, що root має повний доступ, а група читає та виконує доступ. Всередині цього каталогу ви можете створити домашні каталоги для кожного з двох користувачів. Це означає, що домашній каталог користувача більше не матиме форми /home/username, а щось, що містить хоча б ще один компонент каталогу. Це не проблема, ніщо не вимагає, щоб домашні каталоги були названі відповідно до цієї конкретної конвенції.

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