Comments 21
worker_processes 10000000;
Проба пера в переводах. Понравилась тема, привлекла простота изложения и перевода - чем не повод опубликовать на Хабре? Суть вроде бы передал. Где-то есть дискуссионные моменты, а кое-чего вообще не понял: например, про "vue-codemirror ... интеграцию, которая обновляет Vue при обновлении текстового поля" и про "стили и скрипты разделены на несколько файлов".- тут не моя область, пожалуйста, поправьте, если знаете, что имелось в виду.
Сейчас лично мне такая песочница без надобности, но ещё каких-то лет 5 назад я и мечтать о такой штуке не мог (даже в голову не приходило, если честно). Вдруг кому-то пригодится, а может кого-то подстегнёт запилить что-то своё.
У Yandex когда-то был проект gixy, который, честно говоря, распространения не увидел, но это интересный проект, который позволил поправить пару ошибок, со сбросом X-Frame-Options, ЕМНИП.
Здесь же ничего особо интересного, потому что - ну, это просто Nginx. Методом тыка можно сделать что-нибудь, как и на обычной его установке. Очень не хватало профайлера, который пошагово объяснял бы, куда идёт запрос на каждом следующем шаге, со ссылками на документацию для каждой из директив. Вот это было бы мощно.
Да, было бы здорово, если бы эта штука выдавала отладочные логи, а не только ошибки. Типа такого: error_log filename.log debug
Да я бы не сказал, что не увидел распространения. На многих зарубежных сайтах на него ссылаются, но да, сам проект не развивается с 2019, если не ошибаюсь. А штука реально классная.
Идея очень классная и реализация простая.
За счёт netns есть изоляция по сети, но файловая система открыта и можно делать что-то типа
curl file:///etc/passwdФильтровать директивы, как предложили в ветке выше - дело неблагодарное в итоге: не зная всех нюансов использования, можно потратить уйму времени и ничего не решить.
Как вариант, запускать в контейнере с ограничением памяти и таймаутом на работу, но не могу оценить насколько от этого пострадает быстродействие по сравнению с текущей реализацией.
Да, главная стратегия защиты от злоумышленников в том, что защиты почти нет, но и ценного ничего нет тоже.
А про контейнеры автор писала, что мысли были, но производительность бы слишком пострадала. Хотя и мне кажется, что это нормальный способ. Сейчас вообще многое на каждый чих запускается в контейнерах или даже виртуалках. Но это ресурсоёмкая затея, а сервис этот попроще, обычный инди-проект
Оно и так в контейнере судя по содержимому на файловой системе (autoindex on). Просто каждый запуск не изолирован от других. Сходу как минимум пара идей на RCE (и потенциально с выход из докера, т.к. скорее всего есть нужные capabilities), но проверять лень. Тот же докерхаб вообще дает из коробке RCE (сборка докер образов) и никто в этом трагедии не видит.
Я просто использую systemd sandboxing - дешево, сердито и эффективно. Ну и AppArmor для надёжности.
Открываешь консоль gcloud и запускаешь прямо там что угодно. Прямо в этой сессии. Докер не тормозит
Как вариант, можно парсить конфиг и проверять, нет ли чересчур больших значений для каких-нибудь параметров, которые могут уронить сервер. Есть пара библиотек для Go: [1], [2].
Сам когда-то давно писал парсер конфигов, только на сях. Написано криво-косо, но работает до сих пор :)
нормальный конфиг nginx состоит из множества файлов.
посему рекомендую допилить песочницу до использования инклюдов.
в качестве инклюдов инклюдить не файлы, а табы, парся их в файлы, уже на стороне апи.
А что вы выносите в отдельные файлы? Типа, отдельно ssl, отдельно gzip, отдельно каждый локейшн?
А вот как в этом генераторе - мне нравится, как он раскидывает конфиги. NGINXConfig | DigitalOcean
А если собрать nginx webassembly и запускать его прямо у клиента в браузере в песочнице?
Песочница для Nginx