Содержание статьи
Впрочем, даже если в Google действительно использовали этот источник, такое
применение недокументированных функций при виртуализации процессов в Chrome –
далеко не единственное.
MAC против DAC
Частью изолированной среды выполнения Chrome является новейшая
(документированная и полностью поддерживаемая) функция Vista, которая
применяется и в IE8. Vista дополнила модель безопасности Windows NT, внедрив
концепцию под названием полномочное управление доступом (mandatory access
control, MAC). Традиционная система безопасности в NT основывалась на механизме
избирательного контроля доступа (discretionary access control, DAC), который не
является чем-то особенным, поскольку используется во всех типичным образом
защищенных операционных системах. Безопасность на основе DAC – это такая схема,
при которой доступ к объектам из ОС разграничивается в соответствии с
идентификацией членства пользователя в различных группах. Термин "избирательный"
применяется здесь в связи с тем, что пользователь, имеющий права на доступ к
объектам, может делегировать их и другим пользователям. В системах же на основе
MAC, напротив, пользователям запрещено самим аннулировать действующие
разрешения, и они не могут присваивать их другим пользователям.
Чтобы проиллюстрировать разницу этих концепций, приведем следующий пример.
Допустим, в некой компании есть Президент А. и вахтер Б. Президент А. имеет
возможность создания файлов с информацией под грифом "совершенно секретно", а
Вахтер Б. ни при каких обстоятельствах не должен получать к ней доступа, даже
если Президент А. захочет этой информацией с ним поделиться. В системе на основе
DAC Президент может создавать файлы с совершенно секретной информацией, и,
поскольку он является владельцем своих собственных файлов, он может передать
права на их просмотр Вахтеру путем добавления его в список имеющих доступ к
упомянутым файлам.
Однако в системах на базе MAC схема совершенно другая. Президент все также
имеет доступ к файлам категории "совершенно секретно", однако все файлы, которые
он создал, будут также иметь гриф "совершенно секретно", и доступ к ним получат
только те, кто имеет уровень привилегий "совершенно секретно" или выше. Таким
образом, Президенту не удастся снять с файлов отметку "совершенно секретно" и
дать доступ к ним вахтеру. В этом случае доступ называется "полномочным" –
введенные системой ограничения принудительны и не могут быть пересмотрены со
стороны пользователей.
Есть два основных преимущества использования концепции MAC в зависимости от
целей разработчика системы: 1) можно использовать MAC для обеспечения
конфиденциальности (модель
"Bell-LaPadula") и 2) можно использовать эту схему для обеспечения
целостности данных (модель
"Biba"). В системах, спроектированных с прицелом на конфиденциальность (как
в приведенном выше примере), пользователи получают право на чтение файлов,
имеющих такой же или более низкий уровень доступа, чем присвоен самим
пользователям, и право на создание файлов с таким же, или более высоким уровнем
доступа. Такие ограничения делают невозможным создание Президентом файла под
грифом "свободный доступ" и копирование в него совершенно секретных данных,
поскольку все созданные им файлы будут, как минимум, иметь категорию "совершенно
секретно".
В системах, спроектированных для обеспечения целостности, правила игры
меняются на противоположные. Пользователи имеют возможность записи в файлы с
таким же или более низким уровнем привилегий, чем у них самих, и возможность
чтения файлов с таким же или более высоким уровнем доступа. Цель такой политики
состоит не в том, чтобы запретить кому-то видеть то, что он видеть не должен, а
в том, чтобы не дать возможность вносить изменения в файлы, прав на внесение
изменений в которые у пользователя нет. Такую интеграционную модель и
поддерживает Vista. Процесс с низким уровнем привилегий в этой операционной
системе может считывать файлы с более высоким уровнем доступа (чтобы, например,
загрузить DLL, необходимые для его запуска), так же как и записывать файлы в
каталоги с таким же низким уровнем привилегий, как у него, но ему запрещено
записывать файлы в каталоги с более высоким приоритетом (так, например, он не
сможет ничего записать в каталог Windows).
И Chrome и IE8 в Vista пользуются этим. Родительский процесс (ответственный
за прорисовку окна и взаимодействие с пользователем) запускается со средним
уровнем привилегий, а все производные процессы – с низким уровнем. Средний
уровень доступа дает возможность чтения/записи профиля пользователя (позволяя,
таким образом, сохранять загружаемые файлы или применять политики на основе
ранее сохраненных учетных данных). Низкий приоритет позволяет считывать данные
из профиля пользователя, но запись для него возможна лишь в пару временных
каталогов. Ни тот, ни другой уровень доступа не позволяют осуществлять запись в
каталог Windows, поскольку для этого требуется более высокий приоритет.
Chrome, однако, заходит здесь еще дальше, опять влезая на заповедную
территорию.
Chrome поднимает ставки
Для Google защиты Vista недостаточно. В Google хотят, ко всему прочему, еще и
ограничить возможности любого процесса по чтению/записи любого файла, запуску
другого процесса и чтению/записи реестра. Чтобы это осуществить, программисты
частично переписали процессы, отвечающие за вкладки и сторонние приложения, и
теперь любая попытка проведения запрещенных операций проходит проверку на
внутреннем анализаторе Chrome. К примеру, любая попытка открытия файла сверяется
со списком допустимых мест хранения файлов, и, если файл в этот список не
входит, его открытие запрещается, даже если в другом случае процесс и мог бы
получить к нему доступ.
Такая переработка кода затрагивает особые процедуры API. Некоторые из
переписанных заново функций документированы (например, функция CreateProcess), а
некоторые – нет (например, функция чтения атрибутов файла
NtQueryFullAttributesFile не является задокументированной). Многие похожие
функции, используемые в коде, применяются довольно редко, даже сторонними
разработчиками, и, в связи с этим, проведение некоторой работы по
реверс-инжинирингу попросту неизбежно.
Все это ставит на повестку дня весьма интересный вопрос. Цель, с которой
Google использует недокументированные системные процедуры, весьма благородна –
ведь компания всего лишь стремится сделать свой браузер более безопасным и хочет
быть уверенной в том, что влияние потенциальных уязвимостей будет
минимизировано. Однако Windows не предлагает такого системного подхода к
виртуализации процессов, который имеется в Chrome (хотя, очевидно, многие бы
хотели, чтобы он предлагался). Поэтому перед Google стоял трудный выбор – либо
пожертвовать безопасностью (что для большинства совсем не желательно), либо
погрузиться в глубокое изучение операционной системы и нарушить EULA.
Так что, даже если Google действительно декомпилировал Windows, вряд ли
Microsoft подаст на них в суд. Практика реверсирования широко распространена, и
доказать, что Google не использовал для своей работы информацию, поступившую от
третьих лиц, будет практически невозможно. Но должны ли вообще возникать
сомнения в законности подобных действий? Если бы Microsoft предоставил
разработчикам хотя бы самую основную документацию, этого хватило бы, чтобы
создатели Chrome могли спокойно делать свою работу.
Вывод
Microsoft (не без основания) считает, что внутренние функции операционной
системы, используемые в Chrome, могут меняться от одной версии ОС к другой, и
поэтому с большой неохотой придает их огласке. Однако компанию все же заставили
пойти на уступки, и некоторые функции NT сейчас преданы огласке либо по решению
суда, либо чтобы избежать такого решения. И если бы, с необходимыми оговорками о
возможном отсутствии поддержки при последующей эволюции Windows, вся основная
документация по системным функциям была бы все же предоставлена, это сделало бы
разработку приложений, подобных Chrome, полностью законной. При этом в компании
практически ничего не теряли бы – ведь поддержку этих процедур в последующих
версиях ОС можно было бы и убрать.
Аналогичным образом, снятие ограничений на изучение кода в Пользовательском
соглашении (которые уже сейчас практически потеряли смысл) не стоило бы
Microsoft ровным счетом ничего. Оно все равно не избавляет продукты этой
компании от угроз, с которыми ей приходится сталкиваться, а если кто-то
вознамерится декомпилировать код Windows, он спокойно сможет заняться этим в тех
странах, где это не запрещено. А вот помощь разработчикам в выпуске более
качественных приложений для ОС этой компании была бы попросту неоценима.
Конечно, в этом смысле у открытого ПО куда больше преимуществ. Но даже слегка
приоткрыв завесу тайны над своими продуктами, в Microsoft могли бы создать куда
более дружественную среду разработки сторонних приложений для них.
