И почему не Джумла?:)

[qkowlew]

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

Домен зареган 1 ноября 2013.

Сайт залит на хостинг 6 ноября 2013.

8 ноября 2013 в него добавлено минимум три закладки формата "приход с запросом POST на определённый URI сотворяет и исполняет PHP код" и одну формата "создаём ежеминутное задание в кронтаб, исполняющее созданный 1.sh который творит бинарные файлы libworker.so и /usr/bin/host, причём их содержимое зависит от архитектуры. :)

В 2014 и в 2015 годах, явно по случаю продления домена, админы хостинга просыпались и обращали внимание, что сайт что-то делает не то. На тему чего его блокировали и частично очищали от говна (но часть говна, особенно бинарник /usr/bin/host, жила неизменно).

Cледы этого - в тикет-системе хостера, с датами блокировок

24 января (неизвестно, правда, каким кодом, и мне откровенно лень искать) в корне сайта было нагенерено около 80 тысяч статических .html, представляющих собой фишинговые страницы, имитирующие страницы магазинов японоязычного содержания, при этом сделанные как "якобы вы сюда пришли с результатов поиска в Yahoo", но формочки при этом отправляют POST с интересными данными на разные странные адреса.

25 января хостер написал ругательство - исправьте в течение недели а то заблокируем.
Примерно вчера заблокировали.

Иными словами, в течение 2 с лишним лет сайт не столько служил его заказчику, сколько помогал зарабтывать бабло целой пачке злоумышленников.

Сегодня я всего лишь копаюсь в коде этого угробища.

Comments

[qkowlew.livejournal.com]

Это ты невнимателен. :)

Я не говорил, что "мой" путь дешевле или проще.
Я не говорил, что "мой" путь не потребует от разработчика компромиссов.

Я считаю, что если бы за первые реализации http серверов брались, СОБЛЮДАЯ логику "логиненный - анонимный" (замечу - в формате лога того же апача есть инфорация о http логине, и при http авторизации она туда гарантированно попадает) и исполнение кода от соответствующих юзеров и групп - то к нынешнему моменту в качестве базы для реализации любого движка был бы не уродский апач с suexec костылями, а намного более эффективный код, в котором проблема производительности для переключения контекстов, о котором ты плачешь - была бы решена.

Пример перед глазами, реализованный как вполне живой, используемый народом продукт (пусть и не в http, а в mail) - хотя бы qmail, где нет отдельных узеров для всех "почтовых ящиков" или "посетителей", но есть хотя бы чёткое деление процессов по пользователям и по их роли в процессе обработки почты.

Я утверждаю, что завоевание мира логикой "все работаем от рута" в случае http серверов так, как они сейчас массово написаны, УБИЛО самую возможность делать НОРМАЛЬНО безопасный код.

Ты сетуешь о ресурсах разработчика, которые требуются для того, чтобы написать эффективный код в "моей" парадигме. Так в том и дело, что СЕЙЧАС огромные ресурсы разработчиков (время, жизнь) тратятся на то, чтобы разгрести именно состояние "все работаем от рута".

Фишка в том, что рынок эти затраты сейчас только подстёгивают и наслаждают.

Разрабы нагло отвечают "Чтобы исправить эти недостатки нашей CMS - заплатите нам за работу по исправлению примерно столько же, сколько платили нам за разработку". Прекрасно зная, что они могут оставить ЛЮБОЕ количество недостатков в коде - и к ним снова придёт с баблом и протянутой рукой этот заказчик.

Я это наблюдал несколько раз. Причём два случая - сознательно такие, ибо код зашифрован Zend и обфусцирован до невменяемости. Так что и не проверишь. Причём в одном случае, если суметь раззендить и посмотреть на имена файлов - видишь MODX, а не самостоятельно написанный движок. :)

[besm6.livejournal.com]

Мнээ... полуэльф...

Во-первых, куда могла бы деться проблема производительности для переключения контекстов, если для защиты ты полагаешься на ОС? В этом раскладе отдельный залогиненный юзер - отдельный процесс, и никак иначе. Здравствуй, задача инициализации каждого такого процесса. Дальше можно искать компромисс между количеством одновременно запущенных процессов и временем на инициализацию вновь запущенного, но проблема уже стоит, и это - поиск ее кое-какого решения.

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

qmail я, знаешь ли, ставил. Снес довольно быстро, и знаешь, почему? В его модели невозможно проанализировать содержимое письма на этапе SMTP-диалога. В результате не существует корректного работоспособного способа оповестить отправителя о том, что мы отказываемся принять это письмо на основании анализа его содержания. Ну, там и других тараканов хватает. Логика анализа служебной информации у него тоже, мягко говоря, не на высоте. Короче, пока на него реальных задач не вешают, он быстрый и секьюрный.

А разделение ролей по задачам как у qmail (именно как у qmail, а не как у твоей идеи) - ну, так его любой современный движок умеет. Вот рут, от него работает только accept(2) на 80 порту, вот владелец кода, который апгрейдит код сайта, а вот пользователь, от которого этот код выполняется. К сожалению, не то чтобы прям вот все стандартные инструкции заточены под разделение второго и третьего, но уже многие, чесслово. (Тут есть засада - не всегда у разработчика кода сайта есть два логина туда, где он этот код тестирует. В результате он вынужден разрабатывать, совместив этих юзеров.)

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

И кстати, рута-то она реально требует. И далеко не только для того, чтобы занять 80-й порт. Те же описываемые тобой движки работают от одного юзера, но не от рута, как ты тут пишешь. А при нормальном контроле за разработчиками - и не от владельца кода. А твоя идея требует использования рутовых полномочий движком. В полный рост и со сложной логикой. Упс... Дополнительный вектор атаки... Безопасность, говоришь...

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

[qkowlew.livejournal.com]

когда брались за первые реализации HTTP-северов, аутентификации в HTTP еще и в проекте не было

А вот telnet/ssh уже была. Мыль понятна? Я говорю о том, что http реализовывать стали БЕЗ авторизации, хотя опыт разницы в работе "без авторизации" и "с авторизацией" уже вроде как был, хехе. :)

А твоя идея требует использования рутовых полномочий движком.

Нет. Она не требует этого.
Ты невнимательно прочитал.
В работающем сайте "по моей идее" настоящий, операционной системы рут не нужен на исполнение кода сайта нигде.

Чтоб тебя не пугать слово "рут" - заменим его на admin

Рут нужен вебсерверу, да. "Идеальный" вебсервер по "моей" концепции на машине с unix узерами
admin_1 nobody_1 user_1_1 user_1_2 для админа, анонима и узеров 1 сайта,
admin_2 nobody_2 user_2_1 user_2_2 для админа, анонима и узеров 2 сайта,

должен "развести" посетителей в код, исполняемый от соответствующих unix пользователей, причём структура на FS может быть примерно такой:

/www/
 +- admin_1/
     +- user_1_1/
     +- user_1_2/
     +- nobody_1/
     +- site_1_code/
 +- admin_2
     +- user_2_1
     +- user_2_2
     +- nobody_2
     +- site_2_code/

admin_1 работает в своём чруте и имеет доступ к каталогам узеров.
admin_2 работает в своём чруте и имеет доступ к каталогам узеров.

Потому что хотя бы бэкапы взломщик тронуть не сможет - прав не хватит.

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

[besm6.livejournal.com]

> А вот telnet/ssh уже была. Мыль понятна? Я говорю о том, что http реализовывать стали БЕЗ авторизации, хотя опыт разницы в работе "без авторизации" и "с авторизацией" уже вроде как был, хехе. :)

Ну, ssh тоже еще не было. Но вообще-то тут правильная мысль не та, что HTTP начали без авторизации, а та, что HTTP стали применять не по назначению. Видишь ли, HTTP изначально вообще не был предназначен для иной раздачи, кроме публичной. PUT в нем заложили плюс-минус изначально, но он оказался мертворожденным. По сю пору его почти никто не умеет. Ну, DAV-клиенты вроде научились. Без году неделя... Про авторизацию-то сразу подумали, но сразу и решили, что не надо ее закладывать в протокол, кроме кода 401. Есть мнение, что правильно решили-то...

> Чтоб тебя не пугать слово "рут" - заменим его на admin

Ты сам сказал про sudo.

Ну да, при наличии ACL (что уже несколько выбивается за юниксовую модель прав, ну ладно) твоя схема с некоторыми изменениями годится. В смысле, as is она тоже годится, но для совсем уж тривиальных задач. А как только у тебя на сайте появляется две различных роли стаффа, так сразу подавай ACL. Потому что роль реализуется группой, а в юниксовой модели as is группа у файла одна. Ну, к счастью, процесс может разрешить доступ к группе, которой у него своей нет (иначе б облом). Если есть ACL. То есть возможность использовать твою модель у нас намного моложе, чем юникс и HTTP. ACL у нас появились, кажется, в начале 2000-х, хорошо если не в середине первой декады. А во FreeBSD даже и не знаю, есть ли вообще.

В общем, да, без рута можно обойтись. Правда, теперь уже просто файл не создашь, а надо непременно развешивать на него ACL по числу ролей. На каждый. Движком. Откуда, кстати, брать список ACL под данный конкретный файл - тот еще вопрос... Нет, понятно, что из конфига сайта. Только... Там будет уже настолько сложная логика, что это будет уже код. И рутовые права при апдейте этого конфига, поскольку доступ к файлу может поменять либо его владелец, либо рут, а у тебя будет дофига файлов с разными владельцами. Ты все еще полагаешь, что это безопаснее, чем то, что есть? Really?

P.S. За бэкапы. Я реалист. Не всегда можно сделать, как у меня, когда база бэкапится на другую машину раз в час. Более вероятно, что бэкап за пределы хоста удастся делать довольно редко, а еще более вероятно - что такой бэкап будет максимум один, и всей системы целиком, хостеры если предоставляют бэкап, то только такого рода. А база-то немаленькая, в офис в Таганроге ее раз в час не особо забэкапишь. А там еще картинки, и вскоре их тоже станет немало.