Chrooted php-fpm, как давать доступ нжинксу?

[Активист]

Оно тут описано. У пользователя каждого своя группа. В эту группу входит так же веб-сервер. Права доступа вебсервера регулируется правами группы. Хотя ACL мне кажется еще более логичным, но теоретически его, наверно, можно попортить...

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

root@serv001:/var/spool# ls -lash
4,0K drwxr-x---  6 Debian-exim Debian-exim 4,0K Июл 20  2014 exim4
root@serv001:/var/spool# usermod -a -G Debian-exim apelsin
root@serv001:/var/spool# id -Gn apelsin
apelsin Debian-exim mgrsecure
root@serv001:/var/spool#cd /
root@serv001:/# sudo -u apelsin ls -lash /var/spool/exim4/
итого 17M
4,0K drwxr-x---   6 Debian-exim Debian-exim 4,0K Июл 20  2014 .
4,0K drwxr-xr-x   5 root        root        4,0K Июн 19 12:11 ..
4,0K drwxr-x---   2 Debian-exim Debian-exim 4,0K Окт  9  2012 db
4,0K -rw-r--r--   1 root        root         424 Янв 12  2013 gnutls-params
12M drwxr-x---   2 Debian-exim Debian-exim  12M Авг 18 05:23 input
4,7M drwxr-x---   2 Debian-exim Debian-exim 4,7M Авг 18 05:23 msglog
40K drwxr-x--- 942 Debian-exim Debian-exim  36K Авг 18 05:17 scan

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

В свою очередь

root@serv001:/# gpasswd -d apelsin Debian-exim
Удаление пользователя apelsin из группы Debian-exim
root@serv001:/# sudo -u apelsin ls -lash /var/spool/exim4/
ls: невозможно открыть каталог /var/spool/exim4/: Отказано в доступе

Поэтому как я понимаю, решение ispmager'а не связано с проблемой ограничений, а скорее верное решение именно на уровне безопасности.

 

[Фанат]

Так что можно поставить +X-R и в каталог можно будет зайти, но нельзя будет увидеть его содержимого. К безопасности это никакого отношения, конечно, не имеет. Но от любопытных глаз прикроет.

Это-то я как раз понимаю.
И что означает, и что +X-R отношения к данной проблеме не имеет. А вот предложенное выше -X-R - уже очень даже.

Теперь у меня другой вопрос - а как закрывают системные файлы от пользователей - тот же etc?

 

[grigori]

@Активист, а какое отношение к проблеме доступа системных файлов для записи имеет команда
root@serv001:/var/spool# usermod -a -G Debian-exim apelsin
?
если юзер может исполнять код от nginx - у нас очень большие проблемы

> а как закрывают системные файлы от пользователей - тот же etc?
если тебе ssh раздавать не надо, можно сделать chmod o-rx /etc/passwd /etc/group /etc/ssh (себя ж ты уже добавил в группу root)
если надо надежней - можно apparmor/SELinux прописать

 

[Активист]

@Активист, а какое отношение к проблеме доступа системных файлов для записи имеет команда
root@serv001:/var/spool# usermod -a -G Debian-exim apelsin
?
если юзер может исполнять код от nginx - у нас очень большие проблемы

> а как закрывают системные файлы от пользователей - тот же etc?
если тебе ssh раздавать не надо, можно сделать chmod o-rx /etc/passwd /etc/group /etc/ssh (себя ж ты уже добавил в группу root)
если надо надежней - можно apparmor/SELinux прописать

Дк, посмотри внимательно. /var/spool/exim4 имеет права 750, создается от имени Debian-eximebian-exim, таким образом юзер для обеспечения того же почтового трафика получает возможность смотреть весь спул, поскольку добавляется в группу Debian-exim. Или скажем, добавляем пользователя в группу www-data, сокеты могут быть созданы от имени www-data:www-data. Короче, включать пользователя в группу www-data имхо - крайне не безопасно.

 

[Активист]

Это-то я как раз понимаю.
И что означает, и что +X-R отношения к данной проблеме не имеет. А вот предложенное выше -X-R - уже очень даже.

Теперь у меня другой вопрос - а как закрывают системные файлы от пользователей - тот же etc?

Зачем их закрывать? Обычно не закрывают.

 

[Фанат]

если тебе ssh раздавать не надо

Мне надо раздавать SFTP.

 

[Фанат]

Зачем их закрывать? Обычно не закрывают.

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

 

[grigori]

конфиг fpm читается при старте от рута, а от юзеров ты его спокойно можешь закрыть, как и большинство конфигов

 

[Активист]

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

Да норм, пусть смотрят. Сначала пугает, а потом привыкаешь )))))))) Какие-то конфиги можно закрывать правами, они, как говорит grigori в основном запускаются от рута, а потом suid -ятся под нужного юзера.

 

[grigori]

var/spool/exim4 имеет права 750, юзер получает возможность смотреть весь спул, поскольку добавляется в группу Debian-exim. Или скажем, добавляем пользователя в группу www-data, сокеты могут быть созданы от имени www-data:www-data. Короче, включать пользователя в группу www-data имхо - крайне не безопасно.

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

 

[Активист]

Рекомендую закрыть /proc/ для юзеров http://www.cyberciti.biz/faq/linux-hide-processes-from-other-users/ , вот это важный аспект

 

[Активист]

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

А если пользователя добавлять в www-data, можно получить проблему или нет?

 

[grigori]

Мне надо раздавать SFTP.

тогда нет проблем, можно закрывать /etc/passwd и groups чтобы не было видно кто в теремочке живет, он нужен для имени пользователя в командной строке
gri@ubuntu:~$

 

[grigori]

А если пользователя добавлять в www-data, можно получить проблему или нет?

конечно, а если выполнить `find / -delete` можно получить проблему еще больше

 

[Активист]

конечно, а если выполнить `find / -delete` можно получить проблему еще больше

Тут скорее не delete надо делать, а echo -n '' > $1

 

[Активист]

тогда нет проблем, можно закрывать /etc/passwd и groups чтобы не было видно кто в теремочке живет, он нужен для имени пользователя в командной строке
gri@ubuntu:~$

Не всегда, по ним некоторые почтовики определяют, куда складывать почту (если используется maildir). Я на своих хостинговых не закрываю эти данные.

 

[grigori]

да, давай qmail обсудим давненько не обновлялся что-то

я разделяю почту и web-сервер - на yandex можно прикрутить свой домен,
а когда очень хочется, есть postfix с виртуальными пользователями, и очень сомневаюсь, что Фанату оно надо

 

[Фанат]

Да, разумеется - вся почта только через яндекс.
Собственно, ДНС хостится там же.

 

[MiksIr]

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

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

 

[Активист]

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

А как? Разве добавить пользователя в группу www-data - не есть добавить в системную группу "www-data"?