Comments 16
Eval — не зло само по себе, а компиляция во время выполнения. Такая компиляция позволяет сильно ускорить код один раз сгенерировав точные методы под конкретную задачу из диапазона возможных решений. Уменьшить нагрузку на канал в случае очень похожего набора методов. Увеличить переиспользование кода (снизить вероятность возникновения ошибок получающихся при копи-пасте и особенно при последующих изменениях таких частей). Естественно, нельзя исполнять код полученный от клиента и этот инструмент следует очень осторожно использовать, но он ничем не отличается от подгрузки js файла сгенерированного сервером (в него тоже можно включить XSS если есть такое желание или в силу криворукости).
Eval — не зло само по себе… позволяет… снизить вероятность возникновения ошибок получающихся при копи-пасте
Очень сомнительный аргумент. Метапрограммирование обычно лишь повышает сложность как разработки, так и тестирования.
По поводу "13. Запускайте Node.js от имени пользователя, не обладающего root-привилегиями" — несмотря на то, что в контейнере пользователь имеет uid 0 и называется root, реальных рутовых привилегий у него нет, если только контейнер не был запущен с флагом --privileged
, либо нужные привилегии не были добавлены через --cap-add
. Поэтому в чистом контейнере перенаправить iptables невозможно, а привилегии эффективного пользователя не отличаются от таковых у nobody.
Вышеуказанные рекомендации бесполезны. Не навредят, но и пользы никакой.Вы ошибаетесь — не использовать root в контейнере это очень распространенная best practice:
blog.dscpl.com.au/2015/12/don-run-as-root-inside-of-docker.html
opensource.com/business/14/7/docker-security-selinux
medium.com/@mccode/processes-in-containers-should-not-run-as-root-2feae3f0df3b
Так что контейнер не является 100% защитой в этом плане, по крайней мере без использования User Namespaces. Неспроста же облачные сервисы вроде Google Cloud запускают пользовательские контейнеры на отдельных виртуальных машинах — контейнеры не являются надежным методом изоляции.
Может проблема не в руте, а в mount-ах вида docker run --rm -it -v /:/rootfs busybox sh
и полнейшем игнорировании авторами этих "разоблачающих" статей основных принципов работы неймспейсов? Докер запускается с правами рута. При установке докер говорит прямым текстом, что он увеличивает attack surface, поэтому к демону докера должен иметь доступ только рут и судоэры, и добавлять пользователя в группу докера — это риск для безопасности, т.к. фактически выдаются рутовые привилегии. Если кто-то невнимательно читает сообщения при установке, а потом делает из этого сенсацию...
tl;dr — не надо монтировать корневую фс хоста внутрь контейнера, а потом удивляться. Попробуйте лучше вырваться из обычного docker run --rm -it ubuntu
и сделать с хостом хоть что-нибудь.
UPD: увидел в одной из ваших статей, что у контейнера якобы есть доступ к /dev/mem и /dev/sd*. Наверное, у меня неправильный контейнер, потому что вот, что лежит в моем /dev:
root@a78864fc7413:/# find /dev
/dev
/dev/console
/dev/core
/dev/stderr
/dev/stdout
/dev/stdin
/dev/fd
/dev/ptmx
/dev/urandom
/dev/zero
/dev/tty
/dev/full
/dev/random
/dev/null
/dev/shm
/dev/mqueue
/dev/pts
/dev/pts/0
/dev/pts/ptmx
Не понимаю, с чем вы спорите. Как я написал, облачные провайдеры тратят кучу лишних денег на то, чтобы изолировать пользовательские контейнеры. Как думаете, стали бы они это делать, если бы разделяли вашу уверенность в безопасности Docker?
Не говоря уж о том, что прямо в документации Docker написано:
Docker containers are, by default, quite secure; especially if you run your processes as non-privileged users inside the container.docs.docker.com/engine/security/security/#conclusions
С каких это пор cluster.fork() стал безопасной песочницей?
Если приложение не ограничивает количество попыток входа в систему, то атакующий может, в автоматическом режиме, отправить вашей системе неограниченное количество запросов на вход, например, пытаясь получить доступ к привилегированной учётной записи.
А если ограничивает, то атакующий сможет навсегда запретить вход самому админу в админку :)
Не у всех админов есть выделенный IP, к которому можно привязать вход, а не привязанный IP — и вы больше сами никогда не сможете войти в панель, атакующий будет на автомате каждые 5-15 минут пытаться войти, и вы ничего не сможете сделать со своей панелью.
[в закладки] 23 рекомендации по защите Node.js-приложений