Re: apache2+ikiwiki: проблема с suid wrapper
On 2012.08.15 at 21:43:06 +0300, Hleb Valoshka wrote: On 8/15/12, Hleb Valoshka 375...@gmail.com wrote: Моя не понимать Моя понимать: дурная голова. Сам же в /etc/fstab прописал для /home nosuid для безопасности. Осталось вспомнить, от какой именно угрозы защищался таким способом. А то, как известно, защитные меры часто создают свои уязвимости. И всегда надо взвешивать, что потенциально опаснее - исходная угроза, или защита. Как раз ограничения на использование suid-бита - это такая мера защиты, которая очень часто создает больше угроз, чем устраняет. И suexec, кстати, тоже. Собственно сама по себе идея suexec - это сплошная угроза, так как в большинстве случаев выполнение исполняемого файла с правами того, кто может в него писать - угроза (поэтому suid-ные экзешники не принадлежащие руту, вроде ikiwiki-вского враппера желательно держать с правами 4111 или хотя бы 4575). В основном, suexec нужен для shared-хостингов, где у каждого клиента есть ровно один пользователь, и задача изоляции пользователей друг от друга важнее, чем задача защиты пользовательских скриптов от атак через web. Поэтому там, где нет толпы хостинговых юзеров, заливающих свои скрипты по ftp или через web-панели, suexec стоит отключать. Я вообще не понимаю, почему в мире web-хостинга не прижилась система выделения каждому клиенту двух юзеров - одного, от имени которого заливаются файлы, а другого - от имени которого выполняются скрипты. Этакого персонального www-data. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120816073138.gc29...@wagner.pp.ru
Re: apache2+ikiwiki: проблема с suid wrapper
2012/8/16 Victor Wagner vi...@wagner.pp.ru: Я вообще не понимаю, почему в мире web-хостинга не прижилась система выделения каждому клиенту двух юзеров - одного, от имени которого заливаются файлы, а другого - от имени которого выполняются скрипты. Этакого персонального www-data. Потому что CMS. -- С уважением, Константин Матюхин
Re: apache2+ikiwiki: проблема с suid wrapper
12:13 Thu 16 Aug, Konstantin Matyukhin wrote: 2012/8/16 Victor Wagner vi...@wagner.pp.ru: Я вообще не понимаю, почему в мире web-хостинга не прижилась система выделения каждому клиенту двух юзеров - одного, от имени которого заливаются файлы, а другого - от имени которого выполняются скрипты. Этакого персонального www-data. Потому что CMS. Если под CMS подразумевается не Content Managing System, то стоит указать расшифровку. Если же я угадал насчет CMS, то непонятно при чем тут CMS к разделению upload-user и webapp-user. -- WBR, Andrey Tataranovich -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120816082636.ga23...@debbox.it
Re: apache2+ikiwiki: проблема с suid wrapper
On 2012.08.16 at 12:13:04 +0400, Konstantin Matyukhin wrote: 2012/8/16 Victor Wagner vi...@wagner.pp.ru: Я вообще не понимаю, почему в мире web-хостинга не прижилась система выделения каждому клиенту двух юзеров - одного, от имени которого заливаются файлы, а другого - от имени которого выполняются скрипты. Этакого персонального www-data. Потому что CMS. CMS распространились существенно позже, чем suexec Опять же большинство CMS (ikiwiki редкое исключение) хранят контент не на диске, а в БД. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120816083056.ga31...@wagner.pp.ru
Re: apache2+ikiwiki: проблема с suid wrapper
On 08/16/2012 09:31 AM, Victor Wagner wrote: On 2012.08.15 at 21:43:06 +0300, Hleb Valoshka wrote: On 8/15/12, Hleb Valoshka 375...@gmail.com wrote: Моя не понимать Моя понимать: дурная голова. Сам же в /etc/fstab прописал для /home nosuid для безопасности. Осталось вспомнить, от какой именно угрозы защищался таким способом. А то, как известно, защитные меры часто создают свои уязвимости. И всегда надо взвешивать, что потенциально опаснее - исходная угроза, или защита. Как раз ограничения на использование suid-бита - это такая мера защиты, которая очень часто создает больше угроз, чем устраняет. И suexec, кстати, тоже. Собственно сама по себе идея suexec - это сплошная угроза, так как в большинстве случаев выполнение исполняемого файла с правами того, кто может в него писать - угроза (поэтому suid-ные экзешники не принадлежащие руту, вроде ikiwiki-вского враппера желательно держать с правами 4111 или хотя бы 4575). В основном, suexec нужен для shared-хостингов, где у каждого клиента есть ровно один пользователь, и задача изоляции пользователей друг от друга важнее, чем задача защиты пользовательских скриптов от атак через web. Поэтому там, где нет толпы хостинговых юзеров, заливающих свои скрипты по ftp или через web-панели, suexec стоит отключать. Я вообще не понимаю, почему в мире web-хостинга не прижилась система выделения каждому клиенту двух юзеров - одного, от имени которого заливаются файлы, а другого - от имени которого выполняются скрипты. Этакого персонального www-data. кстати эта проблема красиво решается для одного юзера с использованием bindfs -o create-for-user=$user,create-for-group=$group Alex -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/502cb01b.8050...@gmail.com
Re: apache2+ikiwiki: проблема с suid wrapper
On 2012.08.16 at 10:32:27 +0200, Alex Mestiashvili wrote: Я вообще не понимаю, почему в мире web-хостинга не прижилась система выделения каждому клиенту двух юзеров - одного, от имени которого заливаются файлы, а другого - от имени которого выполняются скрипты. Этакого персонального www-data. кстати эта проблема красиво решается для одного юзера с использованием bindfs -o create-for-user=$user,create-for-group=$group Не решается. Потому что юзеру нужно позволить апдейтить и редактировать скрипты. А скриптам - апдейтить и редактировать данные, не все из которых лежат в БД. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120816090945.gb31...@wagner.pp.ru
Re: apache2+ikiwiki: проблема с suid wrapper
On 08/16/2012 11:09 AM, Victor Wagner wrote: On 2012.08.16 at 10:32:27 +0200, Alex Mestiashvili wrote: Я вообще не понимаю, почему в мире web-хостинга не прижилась система выделения каждому клиенту двух юзеров - одного, от имени которого заливаются файлы, а другого - от имени которого выполняются скрипты. Этакого персонального www-data. кстати эта проблема красиво решается для одного юзера с использованием bindfs -o create-for-user=$user,create-for-group=$group Не решается. Потому что юзеру нужно позволить апдейтить и редактировать скрипты. А скриптам - апдейтить и редактировать данные, не все из которых лежат в БД. например: есть сайт который крутится под suphp и скрипты запускаются от юзера xxx. к этому сайту прикручен webdav через который можно редактировать скрипты. для того чтобы скрипты допустим в /var/www/xxx c ownership xxx были видны как www-data для вебдав cоздаем еще одну директорию /var/www/xxx_dav которую монтируем следуюшим образом: bindfs -o create-for-user=xxx,create-for-group=xxx -u www-data -g www-data /var/www/xxx /var/www/xxx_dav теперь все файлы в /var/www/xxx_dav видны как www-data и их можно редактировать, создавать новые и т.д. , при этом в /var/www/xxx файлы видны как созданые от xxx. собственно через webdav вы редактируете файлы в /var/www/xxx_dav , а скрипты запускаются веб сервером в /var/www/xxx . Alex -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/502cbcbc.7040...@gmail.com
Re: apache2+ikiwiki: проблема с suid wrapper
On 2012.08.16 at 11:26:20 +0200, Alex Mestiashvili wrote: например: есть сайт который крутится под suphp и скрипты запускаются от юзера xxx. к этому сайту прикручен webdav через который можно редактировать скрипты. для того чтобы скрипты допустим в /var/www/xxx c ownership xxx были видны как www-data для вебдав cоздаем еще одну директорию /var/www/xxx_dav которую монтируем следуюшим образом: bindfs -o create-for-user=xxx,create-for-group=xxx -u www-data -g www-data /var/www/xxx /var/www/xxx_dav теперь все файлы в /var/www/xxx_dav видны как www-data и их можно редактировать, создавать новые и т.д. , при этом в /var/www/xxx файлы видны как созданые от xxx. собственно через webdav вы редактируете файлы в /var/www/xxx_dav , а скрипты запускаются веб сервером в /var/www/xxx . 1. Вопрос в том, что является в системе более дефицитым ресурсом - user_id или количество смонтированных файловых систем. 2. Типичная security by obscurity. Здесь для того чтобы взломать сайт через дырку в скрипте, нужно всего лишь знать, где именно в файловой системе лежит rw-копия скрипта. Ну либо надо скрипты в chroot запускать, чтобы доступа к rw-копиям себя у них не было в принципе. А системный вызов chroot работает только от рута, да и cgi-environment переписывать придется. В общем - куча новых security implications. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120816100637.ga...@wagner.pp.ru
Re: apache2+ikiwiki: проблема с suid wrapper
On 16.08.2012 13:06, Victor Wagner wrote: On 2012.08.16 at 11:26:20 +0200, Alex Mestiashvili wrote: например: есть сайт который крутится под suphp и скрипты запускаются от юзера xxx. к этому сайту прикручен webdav через который можно редактировать скрипты. для того чтобы скрипты допустим в /var/www/xxx c ownership xxx были видны как www-data для вебдав cоздаем еще одну директорию /var/www/xxx_dav которую монтируем следуюшим образом: bindfs -o create-for-user=xxx,create-for-group=xxx -u www-data -g www-data /var/www/xxx /var/www/xxx_dav теперь все файлы в /var/www/xxx_dav видны как www-data и их можно редактировать, создавать новые и т.д. , при этом в /var/www/xxx файлы видны как созданые от xxx. собственно через webdav вы редактируете файлы в /var/www/xxx_dav , а скрипты запускаются веб сервером в /var/www/xxx . 1. Вопрос в том, что является в системе более дефицитым ресурсом - user_id или количество смонтированных файловых систем. 2. Типичная security by obscurity. Здесь для того чтобы взломать сайт через дырку в скрипте, нужно всего лишь знать, где именно в файловой системе лежит rw-копия скрипта. Ну либо надо скрипты в chroot запускать, чтобы доступа к rw-копиям себя у них не было в принципе. А системный вызов chroot работает только от рута, да и cgi-environment переписывать придется. В общем - куча новых security implications. Что только люди не делают, лишь бы posix acl не использовать -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/502cc696.1020...@kuklin.ru
Re: apache2+ikiwiki: проблема с suid wrapper
On 08/16/2012 12:06 PM, Victor Wagner wrote: On 2012.08.16 at 11:26:20 +0200, Alex Mestiashvili wrote: например: есть сайт который крутится под suphp и скрипты запускаются от юзера xxx. к этому сайту прикручен webdav через который можно редактировать скрипты. для того чтобы скрипты допустим в /var/www/xxx c ownership xxx были видны как www-data для вебдав cоздаем еще одну директорию /var/www/xxx_dav которую монтируем следуюшим образом: bindfs -o create-for-user=xxx,create-for-group=xxx -u www-data -g www-data /var/www/xxx /var/www/xxx_dav теперь все файлы в /var/www/xxx_dav видны как www-data и их можно редактировать, создавать новые и т.д. , при этом в /var/www/xxx файлы видны как созданые от xxx. собственно через webdav вы редактируете файлы в /var/www/xxx_dav , а скрипты запускаются веб сервером в /var/www/xxx . 1. Вопрос в том, что является в системе более дефицитым ресурсом - user_id или количество смонтированных файловых систем. ни то ни другое, даже в случае с fuse bindfs. 2. Типичная security by obscurity. Здесь для того чтобы взломать сайт через дырку в скрипте, нужно всего лишь знать, где именно в файловой системе лежит rw-копия скрипта. Ну либо надо скрипты в chroot запускать, чтобы доступа к rw-копиям себя у них не было в принципе. А системный вызов chroot работает только от рута, да и cgi-environment переписывать придется. В общем - куча новых security implications. это уже другой разговор, я вам предложил вариант решения проблемы с двумя юзерами, а вот приемлем ли он или нет, а также дальнейшая имплементация это ваше дело. Alex -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/502cc8c6.8030...@gmail.com
Re: apache2+ikiwiki: проблема с suid wrapper
On 2012.08.16 at 13:08:22 +0300, alex kuklin wrote: Ну либо надо скрипты в chroot запускать, чтобы доступа к rw-копиям себя у них не было в принципе. А системный вызов chroot работает только от рута, да и cgi-environment переписывать придется. В общем - куча новых security implications. Что только люди не делают, лишь бы posix acl не использовать И как поможет posix acl в данной ситуации? Когда одни процессы, выполняющиеся от имени того же юзера (cgi-скрипты) не должны иметь доступа к определенным файлам, а другие, выполняющиеся от того же юзера (ftpd, dav-сервер) - должны. Примечание: не забывайте что кроме этого юзера у нас есть еще десять тысяч других, и у всех есть ftp-доступ и скрипты. Я тут как раз о том, что если завести двух пользователей, объединенных в группу, то стандартных юниксовых 9 бит permissions за глаза хватит. Единственная засада - вместо 1 пользователей в системе нам придется держать 2 и еще 1 групп. (впрочем, 1 групп у нас вероятно есть и так - из-за привычки современныхс систем по умолчанию создавать для каждого юзера персональную группу) -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120816103345.ga...@wagner.pp.ru
Re: apache2+ikiwiki: проблема с suid wrapper
On 2012.08.16 at 12:17:42 +0200, Alex Mestiashvili wrote: 1. Вопрос в том, что является в системе более дефицитым ресурсом - user_id или количество смонтированных файловых систем. ни то ни другое, даже в случае с fuse bindfs. это уже другой разговор, я вам предложил вариант решения проблемы с двумя юзерами, а вот приемлем ли он или нет, а также дальнейшая имплементация это ваше дело. Так юзеров у нас не два, а 1. И собственно вопрос в том, выдавать каждому по два аккаунта - для него самого и для скриптов, или как-то обойтись одним. Соответственно, в случае с bindfs у нас получается 1 смонтированных bindfs. По-моему, хорошо от этого не будет, и мало не покажется. Alex -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/502cc8c6.8030...@gmail.com -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120816103551.gb...@wagner.pp.ru
Re: apache2+ikiwiki: проблема с suid wrapper
On 8/15/12, Hleb Valoshka 375...@gmail.com wrote: Почему не работает suid из-под апача? Апач не причём. Но всё ещё веселее: один и тот же бинарник кладём в /tmp и ~/public_html, ставим права 06755, вот, всё одинаково ls -ln /home/user/public_html/suid /tmp/suid -rwsr-sr-x 1 1000 1000 8082 Жнв 15 21:25 /home/user/public_html/suid -rwsr-sr-x 1 1000 1000 8082 Жнв 15 21:15 /tmp/suid А теперь запускаем от www-data: $ sudo -u www-data /bin/bash www-data@:/tmp$ /tmp/suid Content-type: text/plain before: uid=33, euid=1000 after: uid=1000, euid=1000 www-data@:/tmp$ /home/user/public_html/suid Content-type: text/plain before: uid=33, euid=33 after: uid=33, euid=33 Моя не понимать
Re: apache2+ikiwiki: проблема с suid wrapper
On 8/15/12, Hleb Valoshka 375...@gmail.com wrote: Моя не понимать Моя понимать: дурная голова. Сам же в /etc/fstab прописал для /home nosuid для безопасности.
