Представьте себе настройку сервера совместно используемой компании веб-хостинга, где несколько (~ 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.
Есть вариант, который вы, возможно, захотите рассмотреть (в зависимости от того, сколько работы вы хотите для этого сделать).
Как уже писали другие, «обычно» вы не можете помешать кому-либо с доступом к оболочке читать файлы, доступные для чтения всем.
Однако вы можете chroot их в их собственный дом, в основном ограничивая доступ к оболочке, во-первых, только желаемым корневым каталогом (он же домашний каталог) и, во-вторых, не позволяйте пользователям выполнять все, что вы не хотите, чтобы они выполняли.
Я применил аналогичный подход, когда у меня был один пользователь, имеющий доступ к веб-файлам, но я не хотел, чтобы он видел другие файлы вне веб-папки.
Это было связано с большими накладными расходами, было беспорядочно настраиваться, и каждый раз, когда я что-то обновлял, оно ломалось.
Но на сегодняшний день я думаю, что вы могли бы довольно легко добиться этого с помощью OpenSSH параметр chroot:
Я обнаружил, что списки управления доступом POSIX позволяют вам, как системному администратору, защитить своих пользователей от наихудшего из их собственного невежества, переопределив обычное разрешение группы пользователей и другой файловой системы, без особых шансов сломать что-либо важное. .
Они могут быть особенно полезны, если вам, например (например), нужны домашние каталоги, чтобы они были доступны всем, потому что веб-контент должен быть доступен для apache в ~/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 (LXC) может быть лучшим сочетанием chroot и отдельной системы.
Они больше похожи на расширенный chroot, а не на виртуализацию, но вы можете комбинировать разные операционные системы на одном сервере.
Вы можете предоставить пользователю полную операционную систему и заблокировать его там, чтобы, когда пользователь входит в систему, он переходит в свой контейнер. И вы также можете ограничить использование процессора и памяти.
Стефан Грабер, автор LXC, имеет хороший руководство чтобы помочь вам начать работу.
Например, если вы хотите, чтобы пользователь имел доступ только к своим home каталог, вам следует сделать:
cd /home
sudo chmod 700 *
Сейчас /home/username виден только его владельцу. Чтобы сделать это значение по умолчанию для всех новых пользователей, отредактируйте /etc/adduser.conf и установить DIR_MODE к 0700 вместо 0755 дефолт.
Конечно, если вы хотите изменить DIR_MODE по умолчанию, это зависит от вашего дистрибутива, тот, который я опубликовал, работает на Ubuntu.
Так как @Dani_l правильно упомянуто, этот ответ правильный, делая их НЕ читаемыми во всем мире.
Просто чтобы быть педантичным - нет, нет.
@Marek дал правильный ответ, но ваш вопрос неверен - вы не можете запретить кому-либо доступ к файлам, доступным для чтения всем.
Либо они доступны для чтения, либо нет. Ответ @Marek верен в том, что делает их НЕ читаемыми.
Я не вижу упоминания о «ограниченной оболочке» в ответах, данных до сих пор.
ln / bin / bash / bin / rbash
Установите это как их оболочку входа в систему.
Если веб-сервер работает как один и тот же пользователь и группа для каждого размещенного домена, сложно (если не невозможно) обеспечить безопасность установки.
Вы хотите, чтобы определенные файлы были доступны пользователю, а также веб-серверу, но не другим пользователям. Но как только веб-сервер получит к ним доступ, другой пользователь сможет прочитать их, поместив символическую ссылку на файл на своем собственном веб-сайте.
Если вы можете заставить каждый веб-сайт работать от имени отдельного пользователя, это становится довольно просто. У каждого клиента теперь будет два пользователя в системе: один для веб-сервера и один для доступа к оболочке.
Создайте группу, содержащую этих двух пользователей. Теперь создайте каталог с этой группой и пользователем root. У этого каталога должны быть разрешения 750, что означает, что root имеет полный доступ, а группа имеет доступ на чтение и выполнение. Внутри этого каталога вы можете создать домашние каталоги для каждого из двух пользователей. Это означает, что домашний каталог пользователя больше не будет иметь форму /home/username, а скорее что-то с еще одним компонентом каталога. Это не проблема, ничто не требует, чтобы домашние каталоги назывались в соответствии с этим конкретным соглашением.
Получить веб-сайты, работающие с разными пользователями и группами, может быть сложно, если вы используете vhosts на основе имен. Если окажется, что разделение работает только с виртуальными хостами на основе IP, и у вас недостаточно IP-адресов для каждого сайта, вы можете разместить каждый веб-сайт на IPv6-адресе и поместить обратный прокси для всех из них на IPv4-адрес.