Представьте себе серверную установку компании, предоставляющей общий веб-хостинг, где несколько (~100) клиентов имеют shell-доступ к одному серверу.
Многие «программы» для работы в интернете рекомендуют присваивать файлам chmod 0777. Я беспокоюсь о том, что наши клиенты могут неразумно следовать этим рекомендациям, открывая свои файлы для других клиентов (я сам, конечно, не использую cmod 0777 без необходимости!). Есть ли способ убедиться, что клиенты могут получить доступ только к своим собственным файлам и предотвратить доступ к файлам, доступным для чтения другими пользователями? Я рассматривал AppArmor, но он очень тесно связан с процессом, который, похоже, не работает в такой среде.
Ответ 1
Есть вариант, который вы, возможно, захотите рассмотреть (в зависимости от того, сколько работы вы хотите для этого сделать). Обычно вы не можете запретить кому-то с доступом к оболочке читать файлы, доступные для чтения другим пользователям.
Однако вы можете сделать chroot в их собственном аккаунте, по сути ограничивая доступ оболочки, во-первых, только к корневому каталогу, который вы хотите использовать (он же домашний каталог), и, во-вторых, не позволяя пользователям выполнять все, что вы не хотите, чтобы они выполняли. Я использовал подобный подход, когда у меня был доступ к веб-файлам для одного пользователя, но я не хотел, чтобы он видел другие файлы за пределами веб-папки. Это имело много накладных расходов, было сложно настроить, и каждый раз, когда я что-то обновлял, это ломалось. Но на сегодняшний день я думаю, что вы можете сделать это довольно просто с помощью опции OpenSSH chroot:
WikiBooks OpenSSH
Ответ 2
Я обнаружил, что списки контроля доступа POSIX позволяют вам как системному администратору защитить своих пользователей от худших последствий их собственного невежества, переопределяя обычные разрешения файловой системы «пользователь-группа-гость», без особого шанса нарушить что-то важное. Они могут быть особенно полезны, если вам, например, нужно, чтобы домашние каталоги были доступны всему миру, потому что веб-контент должен быть доступен для apache в ~/public_html/ (хотя с помощью ACL вы можете сделать обратное: удалить доступ для всех и использовать специальный эффективный ACL для пользователя apache). Да, профессиональный пользователь может удалить/определить их снова, просто они настолько редки, что это маловероятно, а те пользователи, которые могут, обычно не те, кому удобно определять chmod -R 777 ~/ в любом случае, верно?
Вам нужно смонтировать файловую систему с помощью опции acl mount:
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
Теперь установите эффективные разрешения каталога для членов группы пользователей на «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 являются other::rwx. И тестирование в качестве user1:
[user1@access ~]$ ls -la /home/user2
ls: cannot open directory /home/user2: Permission denied
Вторым распространенным решением для систем с общим доступом является монтирование домашних каталогов automounter по требованию на сервере, предназначенном для доступа к оболочке. Это далеко не безошибочное решение, но обычно только несколько пользователей входят в систему одновременно, что означает, что только домашние каталоги этих пользователей видны и доступны.
Ответ 3
Если веб-сервер работает от имени одного и того же пользователя и группы для каждого размещенного домена, трудно (если не невозможно) сделать настройку безопасной. Вы хотите, чтобы определенные файлы были доступны как пользователю, так и веб-серверу, но не другим пользователям. Но как только веб-сервер получает к ним доступ, другой пользователь может прочитать их, поместив симлинк на файл на своем веб-сайте.
Если вы можете заставить каждый веб-сайт работать для отдельного пользователя, то все становится довольно просто. Теперь у каждого клиента будет два пользователя в системе: один для веб-сервера и один для доступа к оболочке.
Создайте группу, содержащую этих двух пользователей. Также создайте каталог с этой группой и пользователем root. Этот каталог должен иметь права 750, что означает, что root имеет полный доступ, а группа – доступ на чтение и выполнение. Внутри этого каталога вы можете создать домашние каталоги для каждого из двух пользователей. Это означает, что домашний каталог пользователя больше не будет иметь вид /home/username, а скорее что-то с еще одним компонентом каталога. Это не проблема, ничто не требует, чтобы домашние каталоги были названы в соответствии с этим конкретным соглашением.
Запуск веб-сайтов с разными пользователями и группами может оказаться сложной задачей, если вы используете vhosts, основанные на именах. Если окажется, что вы можете заставить разделение работать только с vhosts, основанными на IP, и у вас недостаточно IP для каждого сайта, вы можете разместить каждый сайт на IPv6-адресе и поставить обратный прокси для всех них на IPv4-адресе.
Ответ 4
Linux Containers (LXC) может быть лучшей комбинацией chroot и отдельной системы. Это скорее продвинутый chroot, а не виртуализация, но вы можете объединить различные операционные системы на одном сервере. Вы можете дать пользователю отдельную операционную систему и перевести его туда, так что, когда пользователь входит в систему, он попадает в свой контейнер. И вы также можете ограничить использование процессора и памяти.
Linux