Google NaCL (безопасный код в браузере)
Так вот, на мой взгляд, браузер, упакованный в NaCl — это лишь вопрос временипричём время будет его только убивать. Чем дальше, тем меньше распространена x86 архитектура. А у 64 битных приложений уже нет сегментов, а значит нет и NaCl.
было бы круче если работала изоляция в рамках группы динамических библиотек.
чтоб в много-трэдной программе было несколько групп библиотек работающих в nacl.
но у вас похоже без отдельного адресного пространства изоляция не работает до конца.
причём время будет его только убивать. Чем дальше, тем меньше распространена x86 архитектура. А у 64 битных приложений уже нет сегментов, а значит нет и NaCl.я тебя не понял, если честно. NaCl сейчас двигается в сторону Portable NaCl. Основная идея: программа компилируется в LLVM, а затем прям на клиенте очень быстро превращается в машинный код конкретной платформы. Поддерживаются x86, x86-64, ARM.
Соответственно, если у тебя есть программа на PNaCl, ее можно запускать на любой ОС и любой архитектуре из популярных (если тот же MIPS станет важным, сделают такую технологию и для него).
Так вот, повтори свое утверждение еще раз.
изоляция в рамках отдельной таски не кажется мне уж очень эффективной.я пока не понял, почему это неэффективно. Из минусов, которые я знаю (временные это то, что приложение под NaCl компилируется статически, а значит, при наличии нескольких запущенных программ, будет некий расход памяти, которого могло бы не быть (если шарить код динамических библиотек).
было бы круче если работала изоляция в рамках группы динамических библиотек.
чтоб в много-трэдной программе было несколько групп библиотек работающих в nacl.
но у вас похоже без отдельного адресного пространства изоляция не работает до конца.
Прикручивание динамических библиотек в процессе, но в детали я ща не лез.
вот ещё куда вашей соли надо добавить, к вашему-же v8 для компании — http://nodejs.org/
Но желание его запихнуть внутрь NaCl у людей сильное, поскольку это один из наиболее вероятных кандидатов на взлом у хакеров.
При дальнейшем развитии технологии программы станут тру-64 битными и без даунгрейдов.
оставили их для сходных задач по просьбе vmware.
NaCl использует какие-то фичи сегментирования. (возможно википедия лжёт). На 64 битной архитектуре отказались от сегментовоба утверждения верны. Для x86 32 bit используются фичи сегментирования, для 64 бит — другие хаки, для арм — третьи.
Если хочешь конкретики, вот статьи:
x86, 32 bit
ARM и x86-64
PNaCl
сегменты там всё-же есть,и даже сегментные регистры есть. Только согласно документации CS,DS,ES,SS всегда нули. FS,GS правда доступны.
CS...GS это лишь видимые части сегментных регистров, и в защищённом режиме они, как раз-таки, не нули. На нулевых селекторах ты будешь ловить #GP. А нули подставляются вместо базы, вне зависимости от того, что записано в соответствующей закрытой части регистра.
FS и GS являются исключениями, их базы используются. Кроме того, есть MSRы, которые напрямую отображают эти самые базы: FSBASE (C0000100) и GSBASE (C0000101). Последними пользоваться удобно, я гарантирую это.
А Гугл разве не склонен к кроссплатформенности?Почитай тред полностью.
Под exe-шниками в текущем варианте NaCl понимается ELF-файл под одну из архитектур: x86-32, x86-64, ARM, который одинаково запускается под Linux/Mac/Windows. В версии PNaCl (Portable NaCl который дополнит то, что есть сейчас, в качестве входа будет использоваться LLVM модуль, который очень быстро превратится в ELF-файл под текущую платформу и запустится.
Т.е. любая ОСь из списка (Linux/Mac/Windows) и архитектура (x86-32, x86-64, ARM).
Но, если бы чукча был хоть немного читатель, мне не надо было бы писать этот пост.
(в принципе не очень разбираюсь в части flash, silverlight, java)
и в чем nacl будет существенно превосходить flash, silverlight, java.
и вообще есть ли планы создать технологию, которая заменит перечисленные,
либо просто хочется сделать отдельный сегмент "быстрых" и "безопасных" веб-приложений?
silverlight и java (да и флэш) вполне проприетарны, а nacl открыт.
кроме того, сейчас существует toolchain для msvs и gcc, можно будет расшириться и писать быстрые веб-приложения не только на java, actionscript и managed-языках.
и в чем nacl будет существенно превосходить flash, silverlight, java.скоростью (работает со скоростью процессора универсальностью (потенциально, можно тот же flash внутрь NaCl запихнуть возможностью использовать много готового кода.
Кто-то хотел поддержку Ogg, SVG, или TeX шрифтов в браузере? Пожалуйста, можно взять готовый код, скомпилить его и запустить прямо в браузере.
Кто-то хотел писать client-side не на javascript, а на ruby? пожалуйста, берешь уже готовый ruby interpreter, встраиваешь в страницу (причем, если использовать html5 manifest, скачается он только один раз и не выпадет из кеша, пока не попросишь).
Target группы:
1. разработчики игр и игровых платформ. Например, NaCl мегаинтересен ребятам вроде OnLive, которые предлагают игрушки запускать в датацентре, а локальный комп использовать только как монитор, клава, мышка и юзер. Flash игры тоже уперлись в производительность, с помощью NaCl же можно юзать OpenGL.
2. Разработчики нетривиальных приложений, типа online CAD-ов, sound editor, графических/фото редакторов, мб видео-редакторов (видео — если решат проблему хранения гигабайт в html 5 storage). Да банальному Google Spreadsheets не хватает производительности, чтобы цифры считать и это происходит на сервере!
3. Гики. Я вот очень хочу ssh в браузере. Потому что сейчас у меня на компе запущен только браузер и терминал. И терминал меня бесит, поскольку по удобству управления вкладками (почти отсутствует историей (сохраняется на локальном компе паролями (нет особой политики) проигрывает браузеру. На винде мне часто приходится скачивать putty (если, скажем, в гостях, а надо чо-то сделать по-быстрому). Нафига мне чо-то скачивать, если я хочу взять и начать работать. SSH в браузере это решит (сейчас уже есть полурешения, правда).
4. Server-side. Лично я вижу большое будущее NaCl на сервере. И, не только я:
Google's Native Client belongs on the Server, too
Safe Server Side Build and Test
NaCl on Server мне лично нравится больше всего, но сейчас слишком мало сделано для того, чтобы чем-то можно было пользоваться.
html5 уже почти заменил flash (попробуй включи html5 в youtube);каким макаром из того, что youtube умеет показываться на html5 следует, что html5 почти заменил флеш?
silverlight и java (да и флэш) вполне проприетарны, а nacl открыт.java давно уже opensource есть - и что с того? чем тут тебе мешает проприетарность?
opera, ie, chrome, safari вполне себе проприетарны, всем пофиг на это.
кроме того, сейчас существует toolchain для msvs и gcc, можно будет расшириться и писать быстрые веб-приложения не только на java, actionscript и managed-языках.само по себе наличие новой абстрактной возможности не является плюсом.
пользователи будут думать - а нахрена еще одна дырка мне в браузер, если она ничего нового и лучшего мне не дает?
ага, теперь понятно
пользователи будут думать - а нахрена еще одна дырка мне в браузер, если она ничего нового и лучшего мне не дает?утверждение следующее: в отличие от java (десятки миллионов строк, которым приходится доверять nacl — это 10 тыс. строк, которым доверяешь. Остальной код сам работает под nacl и ничего страшного сделать не может, даже если содержит ошибки. Под остальным nacl-овским кодом я понимаю, например, llvm->native code транслятор и прочие вещи, которые не являются основой nacl (валидатор и загрузчик).
Т.е. цель nacl — уменьшить количество дырок на несколько порядков, а не увеличить.
nacl — это 10 тыс. строк, которым доверяешь. Остальной код сам работает под nacl и ничего страшного сделать не может, даже если содержит ошибки.А как он нарисует ТеX-овские шрифты? Разве тут не нужна поддержка браузера?
ради игрушки, или супер-нужного приложения - будут, конечно.
А как он нарисует ТеX-овские шрифты? Разве тут не нужна поддержка браузера?целых два способа, на выбор:
1. можно отрисовать картинки и подсунуть их в javascript
2. браузер дает плагинам окошко, там можно рисовать (с точки зрения браузера, nacl и flash — одна и то же. Ключевое слово NPAPI, ну еще ща появился Pepper ему на замену)
Предлагаю не флудить на тему, зачем это нужно, или что это неудобно. Я все равно не смогу аргументировать без примеров, а примеры будет тяжело показать.
имеется ввиду встраивание библиотек с отрисовкой в страницу (отрисовка работает под nacl)
лишний софт никто ставить не будет просто такв Chrome встроен NaCl. Т.к. в Chrome OS без него совсем тухло. Хотя, конечно, есть плагин для FF, Opera и Safari, для пользователя открыты оба варианта.
целых два способа, на выбор:Ну как бы 10к доверенных строк - это обман. Используется ещё жырный браузер, жырная GUI-подсистема, жырное ядро.
1. можно отрисовать картинки и подсунуть их в javascript
2. браузер дает плагинам окошко, там можно рисовать (с точки зрения браузера, nacl и flash — одна и то же. Ключевое слово NPAPI, ну еще ща появился Pepper ему на замену)
Ну как бы 10к доверенных строк - это обман. Используется ещё жырный браузер, жырная GUI-подсистема, жырное ядро.Поскольку в треде появились писатели, начинаю ставить линки на этот же тред:
10k lines - не обман, в плане, что то, что мы запускаем под nacl — безопасно.
Ядру, кстати, там доверия почти нет (системные вызовы либо запрещены, либо эмулируются. Разрешены только самые простые).
GUI и браузер на безопасность nacl совсем не оказывают влияния: из него ты можешь сделать с браузером столько же, сколько из javascript.
GUI и браузер на безопасность nacl совсем не оказывают влияния: из него ты можешь сделать с браузером столько же, сколько из javascript.То есть дофига.
А в рекламе-то вашей выглядит: вот у нас всего 10к строк доверенного кода (в противоположность другим решениям). А выясняется, это 10к _дополнительных_ доверенных строк.
какие полномочия нужны NaCl для запуска и постройки темницы?
А в рекламе-то вашей выглядит: вот у нас всего 10к строк доверенного кода (в противоположность другим решениям). А выясняется, это 10к _дополнительных_ доверенных строк.нет, не так. Потому что реклама NaCl — отдельно (он может хоть на сервере запускать реклама браузера — отдельно (тот же хром в перспективе вполне в nacl может перелезть. То, что пока не перелез, вполне естественно, т.к. не все сразу).
какие полномочия нужны NaCl для запуска и постройки темницы?никаких. Загрузчик в свое адресное пространство грузит ELF файл и передает управление.
Более того, Chrome гоняет sel_ldr под seccomp, поскольку остальные части хрома тоже под ним запускаются.
ps. sel_ldr — это загрузчик nacl.
То есть не становится код безопасным от того, что он выполняется в виртуальной машине. Если сейчас через дыру в браузере можно например украсть номер кредитки, то и в супер-браузере под супер-виртуальной нано-машиной тоже вполне может быть такая же точно дыра.
Безопасность плавно растворится по мере переезжания всего.Еще nacl не избавит от пользователей, которые вводят пароли на фишинговых сайтов.
То есть не становится код безопасным от того, что он выполняется в виртуальной машине. Если сейчас через дыру в браузере можно например украсть номер кредитки, то и в супер-браузере под супер-виртуальной нано-машиной тоже вполне может быть такая же точно дыра.
Он избавит только от порнобаннеров и надписи "Поздравляем! MegaSearchToolbar установлен на ваш компьютер!" только от того, что ты зашел по ссылке на tinyurl. Кстати, указанную надпись я наблюдал лично, и это был последний раз, когда я выходил в инет с IE 6 (на дворе был примерно 2005 год).
Он избавит только от порнобаннеров и надписи "Поздравляем! MegaSearchToolbar установлен на ваш компьютер!" только от того, что ты зашел по ссылке на tinyurl. Кстати, указанную надпись я наблюдал лично, и это был последний раз, когда я выходил в инет с IE 6 (на дворе был примерно 2005 год).Ну будет баннер установлен внутри виртуальной машины. Это как-то помешает ему появляться?
Ну будет баннер установлен внутри виртуальной машины. Это как-то помешает ему появляться?Внутри какой виртуальной машины, я не понял?
А пока просто: плагинчик, который рисует всякие красивости и ничего при этом не портит, я за! Правда, java-апплеты придумали уже 15 лет назад, но допустим nacl гораздо лучше - охотно в это верю.
А вот если портировать туда офисные тулзы, то из виртуальной машины уже будет доступна деловая информация, что помешает трояну её украсть или заменить на порнобаннер?
Ну то есть, пока мы не хотим, чтобы у плагинчика был доступ к важным для нас данным, всё хорошо. А начинаем портировать тулзы, которым доступ нужен - безопасность растворяется.
Я не вижу нигде слов о том, что nacl решает все проблемы с безопасностью. Он решает только одну проблему: запуска чужого кода на своей машине без риска повредить ее. Что там крутится внутри, nacl не интересует.
ps. Do one thing, but do it best.
Он решает только одну проблему: запуска чужого кода на своей машине без риска повредить ее.а чего умеет чужой код кроме как запускаться? Рисовать, делать запросы к сетке? Если второе разрешено - то, о какой безопасности речь? Чтобы сделать ботнет достаточно этих двух умений - и да здравствует DDOS атаки с компов, на которых есть NaCl
Т.е. проблема дырявого браузера(плагина) в том, что через дыру возможны атаки на данные, которые к посещаемому сайту не имеют никакого отношения. В песочнице будут доступны именно те данные, которые ты сам осознанно в нее пихнул.
Т.е. ты зайдя на сайт gebnya.ru просто прочесть всякие разности не потеряешь своих персональных данных из соседней вкладки на которой открыт твой интернет банк.
Да, надо уже самому думать, что и в какую песочницу пихать. Но мозги тебе пока компьютером заменять не научились и nacl тут не поможет
Он решает только одну проблему: запуска чужого кода на своей машине без риска повредить ее.Ну если у тебя на машине только браузер, а всё интересное - на сервере. То что ты повредишь на ней? Только если физически - но тут ты достаёшь из кладовки такую же новую - и продолжаешь с того же места.
Интересны повреждения не машины, а каких-то других информационных активов.
Т.е. ты зайдя на сайт gebnya.ru просто прочесть всякие разности не потеряешь своих персональных данных из соседней вкладки на которой открыт твой интернет банк.Ну это именно "посмотреть красивости".
А когда ты заходишь на docs.google.com, то твои данные уже не в соседней вкладке, а именно в этой, и доступны именно из этой песочницы. И ты действительно хочешь, чтобы рабочие инструменты имели доступ к этим данным.
а чего умеет чужой код кроме как запускаться? Рисовать, делать запросы к сетке? Если второе разрешено - то, о какой безопасности речь? Чтобы сделать ботнет достаточно этих двух умений - и да здравствует DDOS атаки с компов, на которых есть NaClумеет общаться с
Также легко представить себе тулзу, которая будет запускать nacl файлы как FastCGI — никаких прав у кода не будет, кроме как спросить про web request и отписаться в web response.
Можно запихнуть gcc внутрь nacl (не очень простая задача, т.к. gcc — монстр и дать ему возможность спрашивать исходные файлы, отдавать объектные. И тогда можно сделать публичный сервис компиляции с минимальным оверхедом и не боясь, что процесс компиляции что-то сломает на сервере.
Ну если у тебя на машине только браузер, а всё интересное - на сервере. То что ты повредишь на ней?залезешь в данные других сайтов? украдешь кукисы от флокала?
залезешь в данные других сайтов? украдешь кукисы от флокала?ну так за этим же следит браузер, в котором гораздо более 10к строк
и модель безопасности которого намного сложнее песочницы
ну так за этим же следит браузер, в котором гораздо более 10к строкна этом месте я потерял нить рассуждений и буду отвечать на вопросы только других участников дискуссии.
и модель безопасности которого намного сложнее песочницы
>> и да здравствует DDOS атаки с компов, на которых есть NaCl
> умеет общаться с внешним миромуправляющим процессом по SRPC
> (Simple RPC). Браузер через этот интерфейс просовывает DOM и
> функции js. Таким образом, приложение на nacl становится
> обычным участником web страницы с теми же правами, что и js.
Осталось вспомнить недавнюю атаку на FreeNode вот таким вот js.
---
...Я работаю антинаучным аферистом...
Осталось вспомнить недавнюю атаку на FreeNode вот таким вот js.дай ссылку, пожалуйста. Мне будет интересно почитать.
рекламщик
залезешь в данные других сайтов? украдешь кукисы от флокала?какой код будет следить за тем, чтобы этого не происходило?
т.е. есть два nacl кода - один с сайта forumbgz.ru, другой nacl-код с hack-forumbgz.ru.
какой код смотрит за тем, чтобы nacl-код с hack-forumbgz.ru не имел доступа к данным (кукисы, пароли и т.д.) с сайта forumbgz.ru, но при этом nacl-код forumbgz.ru к этим же данным доступ имел?
какой код смотрит за тем, чтобы nacl-код с hack-forumbgz.ru не имел доступа к данным (кукисы, пароли и т.д.) с сайта forumbgz.ru, но при этом nacl-код forumbgz.ru к этим же данным доступ имел?код хранилища браузера.
т.е. есть два nacl кода - один с сайта forumbgz.ru, другой nacl-код с hack-forumbgz.ru.в такой формулировке - легко
какой код смотрит за тем, чтобы nacl-код с hack-forumbgz.ru не имел доступа к данным (кукисы, пароли и т.д.) с сайта forumbgz.ru, но при этом nacl-код forumbgz.ru к этим же данным доступ имел?
будет две песочницы
и собственно код на 10к строк смотрит, чтоб из каждой из них не было доступа ни к чему снаружи
но иногда мы хотим, чтоб доступ был
ну типа как оплата картой сделана, там перенаправляют на другой сайт, потом обратно
и тогда песочница уже одна, а следит жырный браузер
по этой причине доступ из песочницы наружу (аналогичный тому, что у javascript) есть, его не убрать без сильного ограничения функциональности, и соответственно, недостаточно того, что не будет багов в nacl, надо, чтоб не было их в браузере
но при этом останется единственное гарантированно безопасное применение - игрушка, желательно без обмена данными с сервером (допустим в начале скачивается save-ка, ею инициализируется игра, по завершению происходит обычный браузерный аплод).
только не очень понимаю, чем java хуже
вроде с производительностью там решили вопросы (даже несколько раз, лол)
и 3d api доступно оттуда?
доступно. Как общеявовское, так и частные инициативы вроде Java Monkey.
Мое суровое ламерское мнение такое: такой большой конторе как гугл, нужно просто аццки заботиться о безопасности своего браузера, чистить код, ломать его, валить, нанять стопицот хакеров за призы шоб ломали. Вот это - правЕльный путь.
З.Ы. Кроме прочего видел статьи, вроде "побег из VM-WARE".
Или вообще в инете, может, только под вирт.машиной сидеть?а вот это правильно. Тем более что есть различные удобные варианты, со стартом машины фоном и доставке окон с неё seamless
Или вообще в инете, может, только под вирт.машиной сидеть?Если у тебя скажем отдельно работа, а отдельно инет, то да.
а вот это правильно.
А если ты в этом интернете и работаешь - то понятно, что браузер будет иметь доступ к деловой информации, тогда какая защищённость от виртуальной машины?
Ну на самом деле можно придумать. Но модель безопасности усложнится. В итоге легко получить что-то монстрообразное, типа полноценного ядра ОС.
код хранилища браузера.сколько в нем строчек? и как гарантируется что в них нет ошибок?
нанять стопицот хакеров за призы шоб ломали.Это уже делается и даже первые критические дыры найдены/пофикшены.
сколько в нем строчек? и как гарантируется что в них нет ошибок?Чо-то я ваще не умею объяснять походу.
Забейте на все мои посты в этом треде, они бесполезны...
на самом деле, если это будет простой (и раскрученный) способ создавать песочницы, то, может, и не так уж плохо.
я, например, порой для этих целей sandboxie использую.
но, конечно, это не панацея, иначе
и вообще, про безопасность это замануха, похоже.
гуглу ведь главное все аппликации в веб вытащить, они этого и не скрывают.
Типа гугл - не макромедия и все не будет как с флешем?http://en.wikipedia.org/wiki/Not_Invented_Here
> дай ссылку, пожалуйста. Мне будет интересно почитать.
Вот она.
---
"Мы диалектику учили не по Гегелю.
Бряцанием боёв она врывалась в стих..."
Если да и целью было показать, что sanboxing — это далеко не единственный прием, который надо использовать, чтобы было меньше проблем безопасности, цель достигнута.
Нет.
> Если да и целью было показать, что sanboxing — это далеко не
> единственный прием, который надо использовать, чтобы было
> меньше проблем безопасности, цель достигнута.
Ты не понял, о чём говорил .
А мысль, в общем-то, проста: как только глубина песочницы достигает
достаточных размеров, в ней начинается гниение и поселяется живность.
Ну и толку-то тогда от песочницы?
---
"Прогресс науки обратно пропорционален числу выходящих журналов."
> Я правильно понял, что по ссылке банальный CSRF?А что там? Я читать, вроде, умею.
Нет.
Оставить комментарий
Helga87
Повторюсь, но немного более подробно.Почему портировать браузер (или основные его части) на NaCl офигенно важно?
Сейчас NaCl в браузере используется для того, чтобы безопасно выполнять машинный код с других сайтов. Надо только понимать, что NaCl — это не Flash, который живет в окошке, а это просто способ запустить процесс и наладить с ним interprocess communication.
Основной проблемой безопасности браузера (если забыть про пользователей является наличие нескольких миллионов строк кода, которые исполняются на компе пользователя и имеют доступ к его данным (а также почти неограниченный доступ к сети).
Если упаковать основные части браузера в NaCl и запускать тот же Chrome не как обычный процесс системы, а как процесс системы внутри NaCl, окажется, что мы уже не надеемся на то, что Chrome написан без уязвимостей типа переполнения буфера или стека, а надеемся только на NaCl. Т.е. вместо миллиона строчек, которым доверяем, остается только 10 тысяч. Причем, на эти 10 тысяч смотрят очень внимательно и даже если оказывается, что в текущей версии есть бага, фиксят очень быстро. Причем, x86 версия вышла год назад и сейчас уже в целом почти без багов. Остальные платформы (x64, ARM) пока еще могут содержать проблемы, но их тоже вычищают.
Так вот, на мой взгляд, браузер, упакованный в NaCl — это лишь вопрос времени. Года через 2 это обязательно сделают. Хотя бы потому, что нет аргументов против и есть офигенный аргумент "за" — никому не нравится, когда ты заходишь на сайт, а потом на компе начинается посторонняя жизнь.
Другое дело, это задача большая и за 2-3 месяца никак не сделать, поэтому, если кто захочет на Summer of code с ней идти, надо брать какой-то небольшой кусочек.