Меню
Что нового?

Shared Hosting Security

fixxxer

fixxxer

К.О.
Партнер клуба
CGI-скрипты стандартно выполняются через suexec, с этим-то никаких проблем нет. Запуск PHP как CGI, конечно, сразу же решает проблему секьюрити, но порождает множество других, главные из которых - падение производительности и невозможность использования .htaccess для php_value.
 

Vasily

Guest
Согласен что php as cgi требует гораздо больше ресурсов CPU, но зато меньше памяти, в то время как PHP as Module требует памяти больше.
Но я хочу сказать о том, что safe_mod это не решение проблемы безопасности, а всего лишь ограничение на работу php скриптов.
 

anight

Новичок
Хотелось бы узнать мнение по эти решениям:
http://www.suphp.org/
http://malik.elcat.kg/apache-suexec-php.shtml
http://www.pookey.co.uk/php-security.xml
совместно с open_basedir
что лутше, что хуже ?
Нажмите для раскрытия...
suphp - это всего лишь setuid root cgi + php. со всеми вытекающими последствиями - потеря производительности и потенциальные привелегии root для каждого если найдут ошибку в suphp.

http://malik.elcat.kg/apache-suexec-php.shtml - это всего лишь разжеваная инструкция по установке классического suexec
 

ClayRabbit

Guest
Vasily
Но я хочу сказать о том, что safe_mod это не решение проблемы безопасности
Нажмите для раскрытия...
Решение. Не очень удобное в некоторых случаях, но наименее ресурсоемкое решение. Что оно по-вашему не решает?

fixxxer
невозможность использования .htaccess для php_value
Нажмите для раскрытия...
Даже при safe_mode нада Options запрещать. Т.ч. php_value все одно не будет работать.
 
fixxxer

fixxxer

К.О.
Партнер клуба
Даже при safe_mode нада Options запрещать. Т.ч. php_value все одно не будет работать.
Нажмите для раскрытия...
Ну здрасте приехали. Тогда вообще engine=off и пишите на HTML :D

Safe Mode - вполне себе решение проблем. Просто тут надо подходить с некоторой изобретательностью, а не тупо манипулируя On/Off-ами. Хотя, все решения уже общеизвестны и повсеместно используются, так что вряд ли я открою кому глаза на великие истины.
 

ClayRabbit

Guest
fixxxer
см. http://phpclub.ru/talk/showthread.php?postid=321211#post321211
и мой последующий диалог с AndreyS

Знаете иное решение этой проблемы? Буду премного вам благодарен, если "откроете мне глаза на великую истину" :)

Эта проблема имеет косвенное отношение к пхп. Просто способ чтения чужого файла с правами 644 апачем.
 
fixxxer

fixxxer

К.О.
Партнер клуба
А, ну это я решил патчем FreeBSD. :)

-~{}~ 01.07.04 14:20:

Суть патча - для файлов, принадлежащих UID/GID в диапазоне 10000-29999, и при текущем UID/GID в том же диапазоне права o+r/o+w/o+w игнорятся (считаются не выставлеными).
 

ClayRabbit

Guest
Хотя нет. Не ясно что-то...
Процесс принадлежит юзеру apache.
Почему процесс может прочитать файл a.txt user1:user1 644 но не сможет прочитать b.txt, являющийся симлинком на /home/user2/public_html/config.php user2:user2 644 ?
Как данный патч тут сработает?
 
fixxxer

fixxxer

К.О.
Партнер клуба
У юзера apache UID не обязательно 80, это-то уж легко меняется ;)
А права я устанавливаю UID user GID apache OTHER none + flag SETUID на wwwroot + umask 006.
 

Vasily

Guest
Originally posted by ClayRabbit
Vasily
Решение. Не очень удобное в некоторых случаях, но наименее ресурсоемкое решение. Что оно по-вашему не решает?

По моему мнению, как я сказал оно накладывает только ограничение на PHP скрипты, но не решает проблему безопасности, т.е. файлы всё равно остаются доступными для чтения для other.

Вот про такое решение как предложил flexxer с патчем я ранее не слышал. По моему очень даже нормально. Кстати где взять патч ?
Нажмите для раскрытия...
 
fixxxer

fixxxer

К.О.
Партнер клуба
Для FreeBSD 4.x - у меня, для остального - самому написать.
 

Vasily

Guest
Приношу глубочайшие извинения товарищу fixxxer'у за то что не правильно исполнил его имя... задумался просто.

-~{}~ 01.07.04 14:42:

То что у вас это хорошо, а как его получить ?
 
fixxxer

fixxxer

К.О.
Партнер клуба
Код: 
[size=1]
*** sys/ufs/ufs/ufs_vnops.c     Thr Jan  2 17:50:41 2003
--- sys/ufs/ufs/ufs_vnops.c.new Wed Aug  6 20:02:13 2003
***************
*** 375,380 ****
--- 375,383 ----
                }

        /* Otherwise, check everyone else. */
+       /* patch of the int ufs_access(ap) function for hosting users with uid and gid between 10000 and 29999. (C)2003 Best-Hosting LLC. */
+       if((cred->cr_uid => 10000 && cred->cr_uid < 30000) && ((ip->i_uid => 10000 && ip->i_uid < 30000) || (ip->i_gid=>10000 && ip->i_gid<30000)))
+               return EACCES;
        if (mode & VEXEC)
                mask |= S_IXOTH;
        if (mode & VREAD)[/size]
 

ClayRabbit

Guest
fixxxer
У юзера apache UID не обязательно 80, это-то уж легко меняется
А права я устанавливаю UID user GID apache OTHER none + flag SETUID на wwwroot + umask 006.
Нажмите для раскрытия...
Ну вы пояснили как вы ставите права на файлы.
А что это изменит в приведенном мной примере? И как-таки сработает патч?
(Книжек по *nix'ам не читал, т.ч. звиняйте, если ступлю :) )

-~{}~ 01.07.04 16:53:

Vasily
А чтобы файлы не были доступны для чтения other на public_html ставятся user:apache 750 (или даже на homedir, или где-то по пути от homedir к public_html) и все.
И подозреваю я, что патч г-на fixxxer'а, решает именно эту проблему, а не ту о которой говорил я.
 
fixxxer

fixxxer

К.О.
Партнер клуба
1) применяем опубликованный выше патч. Не забыв включить опцию ядра SUIDDIR, пересобираем оное.
2) Даем апачу UID=GID=10000 (или другой из диапазона, или изменяем патч ;))
3) Ставим умолчальные umask 006 на апача и хостинговых юзеров (например, через login class и etc/login.conf).
4) Проделываем следующий финт ушами.
chmod +s /home/username
chmod +s /home/username/wwwroot
chmod +s /home/username/cgi-bin
chmod -R 660 /home/username
chown -R user_login:apache /home/username

-~{}~ 01.07.04 14:59:

Да, то ли в этом же топике, то ли в соседнем я это уже писал :)
 

ClayRabbit

Guest
Это все ясно.
Ваш патч не дает юзерскому cgi-скрипту читать файлы с чужим uid или gid независимо от реальных прав доступа.
Так?

Так каким боком он отразится на моем примере? Можно по шагам? :)
UID процесса ( cred->cr_uid ? )= ... , UID файла ( ip->i_uid ? )= ... , GID файла = ... . результат - такой-то.
 
fixxxer

fixxxer

К.О.
Партнер клуба
А, про симлинки. Хе. ;) Я тут протупил.

Возможно решение либо на этапе создания (int ufs_symlink(ap)), либо на этапе чтения (int ufs_readlink(ap)) (первое проще), дабы симлинки от юзера апача не резолвились. Или же запретить Апачу использовать FollowSymLinks методом правки сорцов оного.

В общем, я тут зациклился на патчах и был неправ, ибо сам я форкаю апачи под нужным юзером, сделав ugly ugly patch FreeBSD, позволяющий setuid/setgid 80-му UID :) сорри.
 

ys

отодвинутый новичок
fixxxer
> сделав ugly ugly patch FreeBSD, позволяющий setuid/setgid 80-му UID


Ой. А после этого спится то спокойно? :)
 
Войдите или зарегистрируйтесь для ответа.
Сверху