Ограничить пользователя 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 позволяют вам, как системному администратору, защищать своих пользователей от наихудшего их собственного невежества, переопределяя обычное разрешение файловой системы user-group-other без особого шанса нарушить что-либо критически важное. ,

Они могут быть особенно полезны, если вы, например, (fi) нуждаетесь в том, чтобы домашние каталоги были доступны всему миру, потому что веб-контент должен быть доступен для apache in ~/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

Установите это в качестве оболочки для входа.

Если веб-сервер работает как один и тот же пользователь и группа для каждого размещенного домена, сделать установку безопасной (если не невозможной) сложно.

Вы хотите, чтобы определенные файлы были доступны как пользователю, так и веб-серверу, но не другим пользователям. Но как только веб-сервер может получить к ним доступ, другой пользователь может прочитать их, поместив символическую ссылку на файл на своем веб-сайте.

Если вы можете заставить каждый веб-сайт работать как отдельный пользователь, то это становится довольно простым. Теперь у каждого клиента в системе будет два пользователя, один для веб-сервера и один для доступа к оболочке.

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

Получить веб-сайты, работающие с разными пользователями и группами, может быть непросто, если вы используете vhosts на основе имен. Если окажется, что вы можете заставить разделение работать только с Vhosts на основе IP, и у вас недостаточно IP-адресов для каждого сайта, вы можете разместить каждый веб-сайт по адресу IPv6 и разместить обратный прокси-сервер для всех из них на IPv4-адрес.