Модули Sandboxing Node.js - это можно сделать?

Question

Я изучаю Node.js (-awesome-), и я играю с идеей использовать его для создания MUD следующего поколения (онлайн-текстовой игры). В таких играх существуют различные команды, навыки, заклинания и т. Д., Которые можно использовать для убийства плохих парней, когда вы бегаете и исследуете сотни комнат/мест. Вообще говоря, эти функции довольно статичны - вы не можете создавать новые заклинания или создавать новые комнаты. Я бы хотел создать MUD, где код, определяющий заклинания и комнаты и т. Д., Может быть отредактирован пользователями.

У этого есть некоторые очевидные проблемы безопасности; злоумышленник может, например, загрузить несколько JS, которые разворачивают дочерний процесс 'rm -r /'. Я не так забочусь о защите внутренних дел в игре (я стараюсь как можно больше, но на том языке, где все открыто, вы можете так много делать); Я всегда мог отслеживать изменения в коде wiki-стиля и наказывать пользователей, которые, например. сбой сервера или увеличение мощности более 9000 и т. д. Но я бы хотел прочно защитить ОС сервера.

Я рассмотрел другие ответы на подобные вопросы, и большинство людей предлагает запустить изолированную версию узла. Это не будет работать в моей ситуации (по крайней мере, не очень хорошо), потому что мне нужно, чтобы пользовательский JS взаимодействовал с движком MUD, который сам должен взаимодействовать с файловой системой, системными командами, чувствительными базовыми модулями и т. Д. И т. Д. Гипотетически все эти транзакции могут быть JSON-закодированы в движке, отправлены в обработанном песочнице, обработаны и возвращены в движок через JSON, но это дорогое дело, если каждый звонок, чтобы получить хит-очки игрока, должен быть перешел к другому процессу. Не говоря уже о синхронности, которую я бы предпочел избежать.

Так что мне интересно, есть ли способ «изолировать» единый модуль узла. Я думал, что такой песочнице нужно будет просто отключить функцию «требовать», и все будет блаженством. Так что, поскольку я не мог найти что-либо в Google/SO, я решил, что сам поставил вопрос.

Answer 1

Хорошо, так что я думал об этом еще немного сегодня, и я думаю, что у меня есть основная стратегия:

var require = function(module) { 
    throw "Uh-oh, untrusted code tried to load module '" + module + "'"; 
} 
var module = null; 
// use similar strategy for anything else susceptible 

var loadUntrusted = function() { 
    eval(code); 
} 

По сути, мы просто использовать переменные в локальной области, чтобы скрыть узел API от eval'ed кода и запустить код. Еще одним моментом уязвимости могут быть объекты API-интерфейса Node, которые передаются в ненадежный код. Если, например, буфер был передан ненадежному объекту/функции, этот объект/функция мог проложить путь к цепочке прототипов и заменить функцию буфера ключей своей собственной вредоносной версией. Это сделало бы все буферы, используемые для, например, File IO или команды системы трубопроводов и т. Д., Уязвимые для инъекций.

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