Ограничить пользователя Linux файлами, которыми он владеет

24

Представьте себе настройку сервера общей хостинговой компании, в которой несколько (~ 100) клиентов имеют доступ к оболочке к одному серверу.

Многие веб-«софт» рекомендует chmod файлы 0777 . Я нервничаю из-за того, что наши клиенты неразумно следуют этим учебникам, открывая свои файлы для других наших клиентов. (Я, конечно, не использую cmod 0777себя без нужды!) Есть ли способ убедиться, что клиенты могут получить доступ только к своим файлам и запретить им доступ к файлам, доступным для чтения другим пользователям?

Я посмотрел в AppArmor , но он очень тесно связан с процессом, который, похоже, не работает в этой среде.

Phillipp
источник
12
Я бы на самом деле подумал, является ли рекомендация «веб-программного обеспечения» chmod files 0777строго необходимой, т. Е. Устранена ли основная причина проблемы, а не признак того, что таким образом каждый может читать файлы кого-то другого. Во многих случаях рекомендация разрешить полный доступ - это просто дешевый способ избежать обращений в службу поддержки или отсутствие технических навыков для правильной настройки разрешений. Почти ни в одном случае мне не приходилось устанавливать файлы 0777или предоставлять приложениям полный root-доступ по запросу. Обучение пользователей и / или поставщиков очень помогает здесь.
Космическое Оссифрадж
3
@ CosmicOssifrage, пользователи не могут быть обучены так легко, они не хотят читать инструкции или руководства.
Кристиан Чиупиту
12
Любое «веб - программное обеспечение», по- прежнему рекомендует 777 разрешений должно быть принято, и выстрел . Используйте suexecили mpm_itkили подобное.
Шадур
3
@CosmicOssifrage Я не думаю, что Филипп говорит или принуждает пользователей к chmod 0777своим файлам. Я думаю, что он нервничает из-за того, что они собираются loltoturialz.com/php_problemsи сидят chmod 0777самостоятельно, слепо следуя плохо написанной статье. Там действительно нет никакого способа, чтобы помешать им или предотвратить их расстраивать, когда кто-то крадет их вещи.
Кевин - Восстановить Монику
2
@kevin - именно поэтому была создана гарантия. Я почти никогда не видел серьезного устройства (будь то программное обеспечение, куча сценариев или что-то еще) без такого предложения. И хотите верьте, хотите нет - в большинстве корпораций пользователи хорошо знают об этом
Dani_l

Ответы:

34

Поместите ограниченный и неизменный каталог между внешним миром и защищенными файлами, например

/
 ├─ 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.

Кристиан Чиупиту
источник
15

Есть вариант, который вы можете рассмотреть (в зависимости от того, сколько работы вы хотите сделать для этого).

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

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

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

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

Но на сегодня я думаю, что вы могли бы достичь этого довольно легко с опцией chroot OpenSSH :

WikiBooks OpenSSH

Деннис Нолте
источник
chroot для SFTP легко реализовать, но я не уверен, что это так просто для доступа к оболочке. Вы должны настроить chroot со всеми двоичными файлами и библиотеками для каждого пользователя.
Кристиан Чиупиту
2
Это зависит от реализации. В ARCHLINUX есть специальная команда arch-chroot, которая заботится обо всех дополнительных монтируемых привязках и т. Д. Wiki.archlinux.org/index.php/Change_Root#Change_root
Dani_l
@CristianCiupitu это то, что я сделал, разрешив только определенное подмножество команд со связыванием всех необходимых библиотек, вот почему я сказал, что это беспорядок ,
Деннис Нольте
@Dani_l: как насчет установленных пакетов? Команда, arch-chrootкажется, не покрывает это. Кроме того, существует проблема потери дискового пространства со всеми дубликатами. Я не говорю, что это невозможно сделать, просто сейчас это может быть немного сложнее.
Кристиан Чиупиту
1
Что-то, чтобы сделать это намного проще, - использовать UnionFS для привязки пользователей к специальному объединению rootfs в режиме только для чтения и домашнему каталогу для чтения и записи, это означает, что они видят все системные пакеты и двоичные файлы, но запись автоматически выполняется в их домашняя папка. это должно быть связано с созданием 700 разрешений для всех домашних каталогов, иначе пользователи в любом случае смогут читать файлы других пользователей.
Vality
11

Я обнаружил, что списки контроля доступа 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

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

HBruijn
источник
5
Что такое "фи" ? Я не рекомендовал бы использовать сокращения или аббревиатуры, если они не являются классическими, такими как «например», «то есть», «и т. Д.» И, возможно, OP.
Кристиан Чиупиту
3

Linux Containers (LXC) может быть лучшей комбинацией chroot и отдельной системы.

  1. Они больше похожи на продвинутый chroot, а не на виртуализацию, но вы можете объединить разные операционные системы на одном сервере.

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

У Стефана Грабера, автора LXC, есть хорошее руководство, которое поможет вам начать работу.

maniaque
источник
Вы не можете реально комбинировать разные операционные системы, потому что все они должны использовать ядро Linux , но вы можете использовать разные дистрибутивы .
Кристиан Чиупиту
1
Спасибо :) Да, разные операционные системы на основе ядра Linux.
маньяк
@CristianCiupitu вы имеете в виду то же самое идентичное ядро ​​Linux? или вы имеете в виду, что у каждого контейнера может быть своя версия ядра?
Агкс Мех
@agksmehx, все контейнеры LXC совместно используют ядро ​​хоста . Используются только их приложения и библиотеки. Так, например, если у вас есть хост RHEL 7 с контейнером Ubuntu 14.04, будет использоваться ядро ​​RHEL (3.10.0-123), тогда как ядро ​​Ubuntu (3.13.0-24.46) не будет использоваться; Читайте также этот комментарий из учебника. Кстати, так как ядра контейнеров не используются, было бы неплохо удалить их, чтобы сэкономить место на диске.
Кристиан Чиупиту
@CristianCiupitu это то, что я думал. это не было ясно из ответа или комментария, поэтому я хотел уточнить.
agks mehx
3

Например, если вы хотите, чтобы пользователь имел доступ только к своему собственному homeкаталогу, вы должны сделать:

cd /home
sudo chmod 700 *

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

Конечно, если вы хотите изменить DIR_MODE по умолчанию, это зависит от вашего дистрибутива, тот, который я опубликовал, работает Ubuntu.

редактировать

Как правильно заметил @Dani_l , этот ответ верен, поскольку делает их НЕ читаемыми.

Marek
источник
Они называются «читабельными» по определенной причине.
Марк К Коуэн
1
@DennisNolte На самом деле, это помогает, даже если файлы доступны для чтения всем, если они находятся в каталоге, который вы не читали или не выполняли, но вы все равно не можете их прочитать.
Vality
1
@Vality true, удаляя мой комментарий, поскольку он явно неверен.
Деннис Нольте
2

Просто чтобы быть педантичным - нет, нет.
@Marek дал правильный ответ , но ваш вопрос неверен - вы не можете запретить кому-либо доступ к «читаемым» файлам.
Либо они читаемы, либо нет. @ Марек ответил правильно, потому что они НЕ читаются.

Dani_l
источник
2
неправильно, пользователь может выполнить chroot / jail в подпапку, и он не может читать "нормально" читаемые файлы.
Деннис Нольте
1
-1 Я думаю, что вы без нужды критикуете вопрос ОП. Он хочет предоставить своим клиентам страховочную сетку на случай, если они не разбираются в своих разрешениях. Но мне не кажется, что OP не знает, как работают разрешения на доступ к файлам Unix или основные участники безопасности.
Кевин - Восстановить Монику
Кроме того, вы можете поместить файлы в каталог внутри каталога с тысячами разрешений, и никто не сможет получить к ним доступ, даже если эти файлы доступны для чтения всем пользователям.
Vality
никто? даже не рут? ;-)
Dani_l
@Kevin согласился с тем, что мой комментарий критикуется излишне. Однако, Dani_I не должен писать, что он педантичен и не прав. Не утверждая, что я не согласен с остальной частью его ответа.
Деннис Нольте
0

Я не вижу упоминания об «ограниченной оболочке» в ответах, данных до сих пор.

ln / bin / bash / bin / rbash

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

bbaassssiiee
источник
0

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

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

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

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

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

kasperd
источник