Хабрахабр

[Перевод] Курс MIT «Безопасность компьютерных систем». Лекция 7: «Песочница Native Client», часть 1

Массачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год

Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.

Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3
Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3
Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3
Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3
Лекция 5: «Откуда берутся ошибки систем безопасности» Часть 1 / Часть 2
Лекция 6: «Возможности» Часть 1 / Часть 2 / Часть 3
Лекция 7: «Песочница Native Client» Часть 1 / Часть 2 / Часть 3

Она представляет собой технологию песочницы для запуска кода на разных платформах. Сегодня мы поговорим о системе под названием Native Client, которую Google использует в реальном мире. Это на самом деле довольно классная система. Она используется в браузере Chrome, позволяя веб-приложениям запускать произвольный машинный код. Она также иллюстрирует возможности изоляции и своеобразный метод песочницы или разделения привилегий, который называется «изоляцией сбоев программного обеспечения», software fault isolation, не используя для создания песочницы операционную систему или виртуальную машину.

Поэтому, прежде чем мы начнём изучать технические детали системы, давайте выясним, почему эти ребята действительно хотят запустить машинный код? Вместо этого Native Client имеет совсем другой подход к рассмотрению конкретных инструкций в двоичном файле, чтобы выяснить, будет ли безопасно его запускать или нет. Почему же этих парней так волнует возможность запуска кода на платформе x86? Их конкретный интерес состоит в применении этого решения в веб-браузере, где вы уже можете запустить код JavaScript, Flash Player и некоторые другие процессы. Ведь кажется, что это шаг назад.

Аудитория: они хотят получить очень быстрые вычисления.

Даже если это может быть небезопасно в перспективе, оно действительно обеспечивает высокую производительность. Профессор: да, это одно огромное преимущество машинного кода. Есть ли другие причины? Всё, что вы бы не сделали в JavaScript, например, написали бы программу и скомпилировали её, реально будет работать намного быстрее.

Аудитория: запуск существующего кода?

Важно, что не всё может быть написано на JavaScript. Профессор: правильно. Потому что вы можете просто взять существующую библиотеку, например, какой-то сложный графический «движок», который одновременно чувствителен и к производительности, и ко множеству других сложных вещей, которые вы не хотите повторно реализовать, и это будет хорошее решение.
Если вы просто программируете новое веб-приложение, следует ли использовать собственный клиент, если вас не особо заботит наследование или производительность? Так если вы имеете существующее приложение, или, в отраслевой терминологии, «наследуемый» код, который вы собираетесь запустить в интернете, это кажется отличным решением.

Аудитория: тогда вам не нужно использовать JavaScript.

Если вам не нравится JavaScript, то вам не нужно его использовать, верно? Профессор: да, это хорошая причина. Вы можете использовать, например, C, можете запустить код на Python, написать его на Haskell, на любом языке, который считаете более подходящим.

Буквально через секунду мы рассмотрим технические подробности, а сейчас я хочу показать вам простой обучающий демо-ролик, который я получил с сайта Native Client. Итак, это достаточно убедительный список мотивации для запуска собственного кода в браузере, при этом достаточно сложно получить права на такое действие.

Вы можете посмотреть на эту веб-страницу, которая представляет собой HTML-файл, внутри которого имеется куча кода JavaScript. Это довольно просто, потому что можно взять C++ или программу на C и запустить её в браузере.

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

Здесь показано немного кода JavaScript, который необходим в Native Client для того, чтобы взаимодействовать с конкретным модулем NaCl, который мы собираемся запустить. Native Client позволяет вам запустить внутри браузера свой модуль, поэтому код JavaScript может с ним взаимодействовать и получать ответ.

Как это делается? И вы можете отправлять сообщения этому модулю. Когда модуль NaCl ответит, это запустит функцию сообщения в JavaScript. Вы берете объект этого модуля в JavaScript, называете его postMessage и таким образом осуществляете поддержку отправки этого сообщения в модуль NaCl. И в этом конкретном случае в браузере просто всплывёт диалоговое окно.

Единственное, что вам нужно дополнительно сделать, это назначить таким образом модуль NaCl. Так что со стороны JavaScript, это довольно простой интерфейс веб-страницы. Самым интересным здесь является код hello с расширением nmf. То есть вы просто вставляете сюда модуль с определенным ID. Он просто говорит, что здесь есть исполняемый файл, который нужно загрузить и начать работать с ним в среде NaCl.

Интересной частью является эта функция обработки сообщений HandleMessage. Этот машинный код в самом деле похож на любой другой код C++, который вы могли бы написать.

Он выполняет проверку if (message = = ‘hello’). Это класс C++, и всякий раз, когда код JavaScript отправляет какое-то сообщение в Native код, он будет выполнять эту функцию. Это довольно простой материал. Если да, он создаст ответную строку какого-то рода и отправит её обратно. Но для конкретики давайте попробуем запустить его и посмотреть, что при этом происходит.

Здесь я могу перейти к этому URL, и вот мы видим веб-страницу NaCl. Мы можем построить и запустить небольшой веб-сервер, который будет обслуживать эту страницу и модуль Native Client. Модуль получил наше приветственное сообщение от JavaScript, ответил обратно строкой в JavaScript, и код JavaScript инициировал всплывающее диалоговое окно, содержащее этот ответ.

Так что это действительно работает.

Надеюсь, что нет, но мы можем взять этот код и этот буфер и написать в нём кучу какой-то ерунды, например, 65536 и посмотреть, что при этом происходит. Попытаемся узнать, сможем ли мы вызвать сбой Native Client.

Но давайте посмотрим, что произойдет. Надеюсь, это не должно привести к сбою моего браузера, потому что Native Client пытается обеспечить изоляцию.

Мы видим, что вход в модуль по-прежнему успешен, наш браузер не пострадал. Перезапустим веб-сервер. Посмотрим на консоль JavaScript внизу страницы и увидим, что модуль Native Client сообщает нам о сбое модуля NaCl. Однако обмен сообщениями с клиентом не состоялся, поэтому диалоговое окно отсутствует.

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

Давайте рассмотрим еще несколько примеров. Так выглядит быстрая демонстрация этой системы в том виде, в котором вы можете её использовать в роли конечного пользователя или разработчика. Например, как будет работать Native Client, или зачем нам нужен именно такой, а не альтернативный дизайн.

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

Один из вариантов – доверие к разработчику. Итак, что нужно делать, если вы действительно хотите запустить машинный код в браузере? Возможно, вариант такого подхода заключается в том, что вы спрашиваете пользователя, хочет он запустить какой-то фрагмент кода в своем браузере или нет.

Например, вместо всей этой стратегии компиляции Native Client я мог бы просто создать программу на языке C, запустить её в браузере, и он спросил бы меня, хочу я запустить этот сайт или нет? Итак, все примерно понимают, что это за план, верно? Так что это возможно, верно? И если я нажму «да», случайно «накосячив» в памяти браузера, он даст сбой. Это, конечно, решает все эти задачи, но что в этом плохого?

Это один из способов «обойти» данную систему и множеству других систем. Я думаю, плохое заключается в том, что данное решение небезопасно.

Вы могли бы отправить бинарные файлы в IE, браузер на вашем компьютере, и до тех пор, пока они не вернутся с сертификатом от конкретного разработчика, подписанного, скажем, Microsoft или кем-то другим, браузер не будет запускать ваш код. У Microsoft была система под названием ActiveX, которая в основном реализовывала этот план. Как вы думаете, это полезный план?

Аудитория: это вопрос доверия!

Вам действительно нужно немного доверять, что разработчик будет подписывать только те «бинарники», которые не сделают ничего плохого. Профессор: да, это так. В этом случае вы вполне можете получить в будущем определённые проблемы. Но часто нельзя выяснить, плохая ли это вещь или нет, поэтому они просто пишут код C и подписывают его вслепую без выполнения огромного объема работы.

Даже если пользователь хочет быть осторожным, то на самом деле не ясно, каким образом он должен решать? Точно также решение спрашивать пользователя, действительно ли он хочет запустить какую-то вещь, абсолютно не гарантирует безопасность. Мне говорят, что всё нормально, может быть, он создан солидными разработчиками Google.com или Microsoft.com. Предположим, я действительно хочу понять, могу ли я позволить этой программе работать? Даже если я дизассемблирую его код, будет очень трудно сказать, собирается ли он сделать что-то плохое или нет. Однако это исполняемый файл foo.exe и я абсолютно не знаю, что там внутри него. Поэтому пользователю действительно бывает трудно решить, будет ли запуск кода безопасным для системы.

Таким образом, Native Client может выступать в роли механизма, благодаря которому пользователи могут получить некоторую уверенность в том, должны ли они сказать «да» или «нет» какой-то программе.

Он советовал запускать плагин «play extension», или «воспроизвести расширение» в браузере Chrome. Так что на практике, я думаю, здесь должен быть вариант, который предложил наш приглашённый лектор Пол Ян на прошлой неделе. В некотором роде это то же, что спросить пользователя. То есть получается, что перед запуском любого расширения, включая Native Client, вам нужно щелкать по этой штуке. В этом смысле у нас получается двойной механизм безопасности: сначала спросить пользователя, а затем, при положительном ответе, запустить клиент «песочницы», который не позволит обрушить браузер. Но в этом случае, даже если пользователь решит ответить «да», система всё-равно будет в безопасности, потому что в работу включится Native Client.

Это то, что мы рассматривали в 2-х последних лекциях. Таким образом, другой подход, который должен применяться, заключается в использовании «песочницы», реализуемой средствами ОС или аппаратного обеспечения, или же в изоляции процессов.

Если бы у вас было что-то более сложное, вы бы использовали FreeBSD или Capsicum. Возможно, вы бы использовали механизмы изоляции Unix. Linux имеет аналогичный механизм под названием Seccomp, который мы кратко затронули в последней лекции, он тоже позволяет вам делать подобные вещи. Он отлично подходит для изоляции в «песочнице» какого-то фрагмента кода, потому что вы можете ограничить его возможности.

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

Аудитория: может быть, они хотят минимизировать ошибки?

Возможно, они на самом деле беспокоятся об ошибках ОС. Профессор: да, в каком-то смысле они не доверяют операционной системе. А в Capsicum или Seccomp работа выполняется на основе плана изоляции, поэтому достаточно, чтобы в ядре была лишь небольшая верная часть кода, чтобы песочница сохраняла и применяла изоляцию. Вероятно, что ядро FreeBSD или ядро Linux содержит довольно много кода, написанного на C, который они не хотят или не могут проверить на корректность, даже если бы захотели.

Аудитория: поскольку вы получаете гораздо больше способов использовать браузеры, вам придется иметь дело с различными ОС, такими, как iOS и Android, и доступ…

Причём на самом деле разные операционные системы в некотором роде несовместимы друг с другом. Профессор: да, на самом деле, еще одно интересное соображение заключается в том, что обычно у многих ОС есть ошибки. У Mac OS есть Seatbelt, у Windows что-то еще, и этот список можно продолжать дальше. Это означает, что каждая ОС имеет свой собственный механизм, как здесь на рисунке: у Unix есть Capsicum, у Linux есть Seccomp, но это просто вариации Unix.

И то, что на самом деле не слишком сильно их беспокоит, это то, что они должны будут написать разный код для Mac, Windows и Linux. Так что в итоге каждая платформа, с которой вы работаете, имеет собственный механизм изоляции. Потому что в Native Client вы на самом деле пишете часть кода, который выполняется так же, как «родной» код ОС, таким же образом, которым выполняется код Apple, код Windows или код системы Linux. Но в большей степени это влияет на то, как вы должны написать эти вещи для работы внутри песочницы.

Поэтому вам придется написать одну программу, которая будет служить для запуска внутри песочницы Linux, другую программу для запуска внутри песочницы Windows, и так далее. И если использовать эти механизмы изоляции, то они фактически накладывают разные ограничения на программу, помещённую в «песочницу».

Они не хотят иметь дело с проблемами такого вида. Вот что на самом деле для них неприемлемо. Какие ещё соображения у вас есть?

Потому что, если вы применяете Capsicum, вам нужно позаботиться о достаточных ресурсах, чтобы обеспечить работу процессов внутри песочницы. Аудитория:предположительно, производительность системы. Здесь они могут столкнуться с такой же проблемой.

План изоляции сбоев программного обеспечения на самом деле очень ресурсоёмкий, что на уровне ОС может вызвать нехватку ресурсов для обеспечения работы «песочницы». Профессор: да, это правда. Таким образом, на самом деле они не выигрывают в производительности своей реализации, хотя, вероятно, могли бы. Оказывается, что в собственном Native Client они фактически используют и свою «песочницу», и «песочницу» ОС для обеспечения дополнительной безопасности.

Потому что они могут контролировать то, что происходит в браузере, но если они отправили его в ОС на компьютер клиента, они не знают, что там может произойти. Аудитория: возможно, они хотят всё контролировать.

Или интерфейс немного отличается, так что вы не знаете, что собирается выявить операционная система. Профессор: можно сказать, что да, ОС может иметь ошибки или недостаточно хорошо справляться с «песочницей».

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

Я думаю, что один действительно интересный пример, о котором я не знал, пока не прочёл их статью, показывает, что эти ребята беспокоятся об аппаратных ошибках, а не только об уязвимости ОС, которыми может воспользоваться запускаемый код. Профессор: в действительности очень трудно определить, имеет ли место бесконечно зацикленный процесс или нет, но в принципе, такой подход позволяет уловить некоторые проблемы кода. В принципе, ваше оборудование не должно иметь такой ошибки, потому что операционная система полагается на то, что аппаратное обеспечение в любом случае поможет ей достичь ядра, чтобы позаботиться о ликвидации последствий ошибки пользователя. Например, сам процессор имеет некоторые инструкции, из-за которых он может «зависнуть» или перезагрузить компьютер.

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

Так что по поводу безопасности они ведут себя как параноики, включая проблему безопасности аппаратного обеспечения. Таким образом, они захотели создать более высокий уровень защиты для модулей Native Client, чем тот, что обеспечивает изоляция на уровне ОС, даже свободная от аппаратных ошибок.

Таким образом, Native Client использует другой подход, который можно назвать «изоляцией сбоев программного обеспечения». Давайте сейчас посмотрим, как Native Client на самом деле изолирует процессы в «песочнице».

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

Так что то, что они собираются сделать, это посмотреть практически все инструкции в двоичном коде, который отправляется в браузер, и решить, будут ли конкретные инструкции безопасными или нет.

Они просто позволяют им действовать. Что они делают для безопасных инструкций? Наверное, они считают, что безопасная инструкция не нуждается в дополнительных проверках или защите. Что представляет собой пример безопасной инструкции?

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

Я думаю, что это вещи, которые заботят их гораздо больше. А как же небезопасные операции? Может быть, эти процессы попытаются «выпрыгнуть» из песочницы, кто знает? Это всё то, что обеспечивает доступ к памяти, или выполняет некоторые привилегированные инструкции, или осуществляет системный вызов на данном компьютере. Для такого рода инструкций они собираются выполнить одну из двух вещей.

Или если вы «прыгаете» в адресном пространстве программы, то они постараются каким-то образом инструментировать инструкцию. Если инструкция действительно необходима для работы приложения, например, обеспечивает ему доступ к памяти, то они собираются каким-то образом убедиться, что могут выполнить эту небезопасную инструкцию безопасным образом. Потому что иногда инструкция может делать плохие вещи, а инструментация означает, что вы добавляете перед ней некоторые дополнительные условия, которые будут её проверять или использовать, если её выполнение не наносит никакого вреда.
Например, при обращении к памяти вы могли бы сделать (они отказались от этого из соображений производительности) инструментацию доступа к памяти. Инструментация инструкции означает, что небезопасная инструкция будет выполнять «правильные» вещи, которые требует от неё приложение. Например, можно установить перед инструкцией оператор if для проверки, находится ли адрес в диапазоне адресов, разрешённых для данного модуля. Для этого нужно установить несколько проверок. Если это так, инструкция выполняется, если нет – не выполняется.

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

Как только вы проверили двоичный файл приложения, и он удовлетворяет всем условиям и всё инструментировано должным образом, вы можете просто запустить программу. Это своего рода великий план изоляции программных сбоев. И по определению, она не должна совершить ничего опасного, если мы сделали все эти проверки и применили инструменты.

Он не сможет получить доступ к сети, к диску, к вашему браузеру, дисплею, клавиатуре. Есть еще одна часть в истории изоляции ошибок программного обеспечения, которая состоит в том, что когда вы убедитесь, что всё безопасно, то процесс действительно не сможет сделать что-то опасней, чем вычисления в собственной маленькой памяти. Поэтому доверенная служба может выполнять все эти потенциально опасные действия. Но почти каждая история изоляции ошибок программного обеспечения заключается в существовании некоторых доверенных служб Trusted Service Runtime, которые не подвергаются проверкам инструкций. Так что они надеются, что с реализацией NaCl всё будет в порядке. В данном случае это доверенное приложение написано разработчиками Google.

И все они подвергаются действию этого изолированного модуля, который должен обеспечивать нормальность выполнения операций предсказуемым способом. Здесь могут быть такие вещи, как выделение памяти, возможно, создание потока, может быть, общение с браузером — мы видели, как система посылает ему сообщение — и так далее.

Или же модуль в любом случае изменит вещи, которые могут привести к неправильной работе? Аудитория: интересно, мы должны разрабатывать это приложение с учётом того, что оно будет отправлено в модуль NaCl?

Поэтому некоторые вызовы функций, такие как malloc или pthread_create, просто прозрачно совмещаются с вызовами их Trusted Service Runtime. Профессор: я думаю, что если вы создаете приложение, вы должны знать, что оно будет работать внутри NaCl. Вероятно, вы захотите структурировать свою вещь, чтобы хотя бы немного взаимодействовать с вашим JavaScript или вашей веб-страницей. Но если вы сделаете что-нибудь вроде открытия файла по имени пути или подобное, что можно сделать на компьютере под управлением Unix, вам наверняка придется заменить это действие чем-то другим. Поэтому вам придётся передавать некоторые сообщения или RPC в часть JavaScript, то есть вам придётся внести изменения в свой код.

Возможно, если очень постараться, можно попробовать запустить в NaCl произвольную Unix-программу, поместив её в какую-то оболочку, но по умолчанию вы можете работать только внутри этой веб-страницы.

Давайте рассмотрим, что означает безопасность в случае использования Native Client. В этом заключается общий план изоляции программных ошибок. Мы только что поговорили о безопасных и небезопасных инструкциях – что в них может волновать разработчиков Native Client?

Одна это то, что там нет запрещенных инструкций, которые он может выполнить. Насколько я могу судить, для Native Client безопасность означает две вещи. Вероятно, он также не позволит выполнить другие привилегированные инструкции, которые позволили бы вам выбраться из «песочницы», позже мы рассмотрим эти инструкции. И эти запрещенные инструкции могут совершать такие вещи, как системные вызовы или запуск взаимодействия, что на платформах x86 является еще одним механизмом для перехода к ядру и осуществления системного вызова.

Это означает, что они фактически выделяют определенную часть пространства программных адресов, обычно это составляет от 0 до 256 МБ на процесс. И в дополнение к отсутствию запрещенных к выполнению инструкций они хотят убедиться, что весь код и доступ к данным находятся в пределах модуля. И всё, что могут сделать процессы, которые не входят в число доверенных, это обратиться к адресам, которые находятся в пределах этой зарезервированной в программе памяти.

И что случится, если они не смогут их запретить? Так почему же они хотят запретить эти инструкции?

Аудитория: вероятно потому, что модуль может манипулировать системой.

Например, он может перезагрузить компьютер или открыть домашний каталог, перечислить все файлы и выполните любые подобные действия. Профессор: верно, потому что это довольно просто. Что пойдет не так, если они этого не сделают? Почему они заботятся о том, чтобы изолировать код и данные так, чтобы они получали доступ только к этим ограниченным адресам?

Аудитория: потому что код или данные могут получить доступ и прервать выполнение модуля на компьютере.

Профессор: правильно!

Но они могут нарушить работу всей системы. Аудитория: нам всё-равно, если они разрушат работу своей собственной программы, и она даст сбой.

Но в их случае, они фактически управляют вещами в отдельном процессе. Профессор: да, в некотором смысле это правда. Я думаю, что в действительности их больше беспокоят незапрещённые инструкции в том смысле, что в вашем процессе есть такие вещи, как Trusted Service Runtime. Таким образом, в теории, это будет только сбой в дополнительном процессе. Таким образом, запрет инструкций действует как вспомогательный механизм для предотвращения подобного случая. Так что вы действительно заботитесь о том, чтобы они не разрушили остальную часть вашего компьютера, если ненадежный модуль произвольно перейдёт в доверенную среду Trusted Service Runtime и сделает всё, что может сделать эта среда.

Но из соображений производительности они действительно должны привязать модуль к этому определенному диапазону памяти, или же она должна начинаться с 0. В принципе, это может быть использовано как вариант более легкой изоляции, если вы можете запустить модуль NaCl внутри самого процесса браузера, а не запускать дополнительный процесс. Поэтому вы в любом случае должны начать отдельный процесс. Это означает, что вы можете иметь только один действительно ненадежный модуль NaCl для каждого процесса.

28:00 мин

Продолжение:

Лекция 7: «Песочница Native Client», часть 2 Курс MIT «Безопасность компьютерных систем».

Полная версия курса доступна здесь.

Вам нравятся наши статьи? Спасибо, что остаетесь с нами. Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? Хотите видеть больше интересных материалов? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

3 месяца бесплатно при оплате новых Dell R630 на срок от полугода — 2 х Intel Deca-Core Xeon E5-2630 v4 / 128GB DDR4 / 4х1TB HDD или 2х240GB SSD / 1Gbps 10 TB — от $99,33 месяц, только до конца августа, заказать можно тут.

класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки? Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 ТВ от $249 в Нидерландах и США! Читайте о том Как построить инфраструктуру корп.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть