LINUX.ORG.RU

Разграничение прав доступа виртуальных пользователей PROFTPd

 ,


0

1

Добрый день.

*** CentOS *** Proftpd ***

Есть две директории для сайтов:

/home/http/site1
/home/http/site2

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

1. Apache, Proftpd запускаются от пользователя apache
2. Соответственно для обеих каталогов /home/http/site1 и /home/http/site2 назначен владелец apache.
3. На основании системного пользователя apache, созданы два виртуальных пользователя proftpd - первый не может выходить выше /home/http/site1, второй не может выходить выше /home/http/site2

Через ftp-клиенты нет проблем, каждый из разработчиков имеет доступ только к своей определенной директории и все хорошо. Но!

Разработчик сайта /home/http/site1 заливает на свой сайт вирус, через который выходит за пределы своей директории и свободно гуляет абсолютно по всем директориям системы, и мало того, так как у него системный пользователь apache, то он не только может просматривать абсолютно все файлы системы, но еще и создавать/редактировать файлы другово разработчика /home/http/site2 - больше того скажу, что он даже видеть не должен конфигурационные файлы из /home/http/site2, т.к. там информация о доступе как к БД MySql так и к админке сайта /home/http/site2.

PHP-вирус такой есть, думаю не для кого это не секрет.

Что делать?

Разработчик сайта /home/http/site1 заливает на свой сайт вирус

Как минимум chroot (из которого при определенном умении можно выйти), оптимум - контейнеры.

dvrts ★★★ ()
Ответ на: комментарий от dvrts

оптимум - контейнеры.

Можешь пжл подсказать, в какую сторону смотреть по поводу контейнеров на CentOS (я не знаком с этим вообще)

Nezhnayka28 ()

Добавить ещё одного пользователя!

darkenshvein ★★★★★ ()
Ответ на: комментарий от dvrts

Я правильно понимаю, что для контейнерной виртуализации:

1. Необходимо разворачивать контейнерную виртуализацию на пустой OS, когда там еще ничего не стоит?

2. Для каждого контейнера необходимо отдельно устанавливать все пакеты (например php, mysql, apache), либо установить вначале все необходимые пакеты в один контейнер, а потом клонировать его?

3. Какую лучше контейнерную виртуализацию выбрать: LXC или OpenVZ с учетом того, что основное направление сервера - это веб-сервер и почтового-сервер с возможностью разграничения пользователей?

p.s: Приходит понимание, что на самом деле, если речь идет о многопользовательской системе и 100% разделении прав пользователей, без виртуализации не обойтись - как не печально (((

Nezhnayka28 ()
Ответ на: комментарий от Nezhnayka28

Добавить ещё одного пользователя!

и этот пользователь так-же сможет ходить по системе, просматривать конфиги, включая и все то, что лежит в каталоге соседа-веб-разработчика?

Nezhnayka28 ()

как вариант перейти на nginx+php-fpm, тогда можно запускать каждый сайт под отдельной учеткой

JB ★★★★★ ()
Ответ на: комментарий от JB

как вариант перейти на nginx+php-fpm

многие движки требуют обязательно апачевский rewrite

+

вопрос-утверждение: при контейнерной виртуализации можно сделать, чтобы отдельной учетке нельзя было просматривать содержимое /etc?

Nezhnayka28 ()
Ответ на: комментарий от Nezhnayka28

вопрос-утверждение: при контейнерной виртуализации можно сделать, чтобы отдельной учетке нельзя было просматривать содержимое /etc?

у тебя в контейнере будет по сути отдельный экземпляр системы, которая с основной делит только ядро. К /etc основной системы доступа там конечно не будет

JB ★★★★★ ()
Ответ на: комментарий от JB

у тебя в контейнере будет по сути отдельный экземпляр системы

и на каждый отдельный экземпляр системы необходимо будет устанавливать ПО? Т.е. в моем случае, мне нужно всего лишь, чтобы веб-разработчик_1 не мог просматривать директорию веб-разработчика_2, а веб-разработчик_2 не мог просматривать директорию веб-разработчика_1, плюс оба не могли смотреть в /etc, где конфигурационные файлы почтового-сервера, но при этом у обоих одно и то же ПО (например apache+nginx+mysql+php) и настройки для этого ПО должны быть одинаковыми для обоих, как в этом случае делается в плане установки и конфигурации ПО?

Nezhnayka28 ()
Ответ на: комментарий от Nezhnayka28

представь что у тебя два сервера вместо одного. Представил? Вот примерно так у тебя и будет

И я в очередной раз не вижу смысла скрывать /etc. Те места где лежат пароли и так доступны только руту, а конфиги скрывать вообще странная затея

JB ★★★★★ ()
Ответ на: комментарий от JB

представь что у тебя два сервера вместо одного

это больше похоже на полную виртуализацию.

а в чем тогда смысл контейнерной виртуализации?

Nezhnayka28 ()
Ответ на: комментарий от Nezhnayka28

смысл в том, что ядро одно на всех, а значит накладных расходов меньше, но и ограничения тоже есть. С определенной точки зрения контейнер это очень продвинутый chroot

JB ★★★★★ ()
Последнее исправление: JB (всего исправлений: 1)
Ответ на: комментарий от JB

Мне просто нужно как в первом посте описал чтобы веб-разработчик_1 не мог смотреть в директорию веб-разработчик_2, а веб-разработчик_2 не мог смотреть в директорию веб-разработчик_1, уже не беру /etc/.

Но nginx+apache+php+mysql - общее ПО с одними и теми же настройками и apache - владелец и у директории /home/http/site1 и у директории /home/http/site2, иначе apache не сможет с ними работать и proftpd от учетки apache запускается, иначе виртуальные пользователи proftpd не смогут получить доступ к /home/http/site1 и /home/http/site2

как сделать в конечном итоге правильно сделать?

Nezhnayka28 ()
Ответ на: комментарий от Nezhnayka28

Все равно дыра остается, а именно: Так как для корректной работы сайтов необходимо на все директории сайтов поставить права 755, а на все файлы 644,то посредством PHP Веб-разработчик_1 может просмотреть каталоги и файлы site2, а Веб-разработчик_2 может просмотреть каталоги и файлы site1.

Здесь конечно выходом может стать - поставить права 440 на конфигурационные файлы сайтов и забить на эту ситуацию, но думаю это как минимум плохое решение.

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

readfile(«/etc/passwd»);
и вижу в браузере содержание данного файла. Так-же можно было на виртуальных хостах сделать так:
php_admin_value open_basedir «/home/http/site1» 
php_admin_value open_basedir «/home/http/site2»
и тем самым запретить выходить PHP за пределы корневой директории сайта, но тут другая проблема - практически все известные PHP-движки начинают работать некорректно при этом и испытывать проблемы, вообщем этот вариант отпадает.

Млинский млин, что еще можно сделать?

Nezhnayka28 ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.