Способ ограничения доступа образа машинного кода к ресурсам операционной системы

Изобретение относится к области категоризации образов сборок. Техническим результатом является повышение безопасности устройства путем ограничения доступа образа машинного кода, имеющего категорию доверия недоверенный, к ресурсам, предоставляемым операционной системой. Способ ограничения доступа образа машинного кода к ресурсам, предоставляемым операционной системой, в котором: а) ограничивают доступ на запись к по меньшей мере одному образу машинного кода; б) определяют родительскую сборку, где родительской сборкой является сборка, на основании которой создан образ, доступ на запись к которому ограничен; в) заменяют образ, доступ к которому ограничен, образом, созданным на основании определенной родительской сборки; г) определяют категорию доверия определенной родительской сборки; д) назначают категорию доверия, определенную для родительской сборки обновленному образу машинного кода; е) ограничивают доступ образа машинного кода, имеющего категорию доверия недоверенный, к ресурсам, предоставляемым операционной системой. 3 з.п. ф-лы, 9 ил.

 

Область техники

Изобретение относится к способам категоризации неизвестных образов сборок, созданных на устройстве.

Уровень техники

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

Подобными файлами являются образы сборок в машинном коде (native image), которые являются частью технологии .NET. Приложения .NET создаются за счет использования вместе некоторого количества сборок (assembly), где сборка является двоичным (бинарным) файлом, обслуживаемым общеязыковой исполняющей средой CLR (Common Language Runtime).

Сборка .NET включает в себя следующие элементы:

- заголовок файла РЕ (portable execution);

- заголовок CLR;

- CIL код (Common Intermediate Language);

- метаданные используемых в сборке типов (классов, интерфейсов, структур, перечислений, делегатов);

- манифест сборки;

- дополнительные встроенные ресурсы.

РЕ заголовок указывает на тот факт, что сборка может загружаться и использоваться в операционных системах семейства Windows. Заголовок также идентифицирует тип приложения (консольное, приложение с графическим пользовательским интерфейсом или библиотека кода).

Заголовок CLR представляет собой данные, которые должны обязательно поддерживать все сборки .NET для того, чтобы они могли обслуживаться в CLR среде. Заголовок CLR содержит данные, например такие, как флаги, версии CLR, точку входа (в частном случае адрес начала функции Main()), которые позволяют исполняющей среде определять компоновку управляемого файла (файла, содержащего управляемый код).

Каждая сборка содержит CIL код, который является промежуточным кодом, не зависящим от процессора. Во время выполнения CIL-код компилируется в режиме реального времени посредством JIT (just in time, т.е. динамическая компиляция) компилятора в инструкции, соответствующие требованиям конкретного процессора.

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

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

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

Сборка может состоять из нескольких модулей (module). Модуль - часть сборки, логическая коллекция кода или ресурсов. Иерархия используемых в сборке сущностей такова: Сборка->модуль->тип(класс)->метод. Модуль может быть внутренним (внутри файла сборки) или внешним (отдельный файл). Модуль не имеет точки входа и не обладает никаким индивидуальным номером версии и поэтому не может напрямую загружаться CLR средой. Модули могут загружаться только главным модулем сборки, например файлом, в котором содержится манифест сборки. Манифест модуля содержит только перечисление всех внешних сборок. Каждый модуль имеет идентификатор MVID (Module Version Identifier) - уникальный идентификатор, прописанный в каждом модуле сборки, который изменяется при каждой компиляции.

В однофайловых сборках все необходимые элементы (заголовки, CIL код, метаданные типов, манифест и ресурсы) размещаются внутри единственного файла *.ехе или *.dll. На Фиг. 1а показано устройство однофайловой сборки.

Многофайловая сборка состоит из набора модулей .NET, которые развертываются в виде одной логической единицы и снабжаются одним номером версии. Формально один из этих модулей называется главным модулем и содержит манифест сборки (а также все необходимые CIL-инструкции, метаданные, заголовки и дополнительные ресурсы).

В манифесте главного модуля описаны все остальные связанные модули, от которых зависит работа главного модуля. В частном случае второстепенным модулям в многофайловой сборке назначается расширение *.netmodule (Фиг. 1б); обязательным требованием для CLR среды это не является. Во второстепенных модулях *.netmodule тоже содержится CIL-код и метаданные типов, а также манифест уровня модуля, в котором перечислены внешние сборки, необходимые данному модулю.

Как и любой РЕ-файл, сборка может быть подписана электронно-цифровой подписью Х.509, располагающейся в оверлее РЕ-файла или каталоге (каталожная подпись). Дополнительно или отдельно используется StrongName подпись - хеш, сгенерированный с применением содержимого сборки и секретной части RSA-ключа. Хеш располагается в сборке между заголовком РЕ и метаданными. Хеш позволяет проверить неизменность сборки с момента компиляции. Для однофайловой сборки при компиляции файла после РЕ заголовка оставляют свободные байты. Затем считается хеш файла с применением секретного ключа и полученный хеш записывается в указанные байты.

Для многофайловых сборок технология отличается. Кроме хеша основного файла сборки, считаются также хеши внешних модулей, после чего данные записываются в основную сборку. Модули не имеют собственных подписей и имеют отличные от главного модуля MVID. В манифест сборки записывается:

- PublicKey - открытая часть StrongName-подписи;

- PublicKeyToken - хеш открытой части ключа StrongName-подписи.

Сборки разделяют на: приватные (private) и публичные (public/shared). Приватные сборки должны всегда размещаться в том же каталоге, что и клиентское приложение, в котором они используются (т.е. в каталоге приложения), или в одном из его подкаталогов.

Публичная сборка одновременно может использоваться в нескольких приложениях на одном и том же устройстве. Публичные сборки не размещаются внутри того же самого каталога, что и приложения, в которых они должны использоваться. Вместо этого они устанавливаются в глобальное хранилище (кэш) сборок (Global Assembly Cache - GAC). GAC располагается сразу в нескольких местах:

Сборка, устанавливаемая в GAC, должна иметь строгое имя (strong name). Строгое имя является современным .NET-эквивалентом глобально уникальных идентификаторов (GUID), которые применялись в СОМ. В отличие от GUID-значений в СОМ, которые представляют собой 128-битные числа, строгие имена .NET основаны (отчасти) на двух взаимосвязанных криптографических ключах, называемых открытым (public) и секретным (private) ключом.

Строгое имя состоит из набора взаимосвязанных данных, включающих:

- именя сборки (которое представляет собой имя сборки без файлового расширения).

- номер версии сборки;

- значение открытого ключа;

- значение, обозначающего регион, которое является необязательным и может предоставляться для локализации приложения;

- цифровой подписи, созданной с использованием хеша, полученного по содержимому сборки и значению секретного ключа.

Для создания строгого имени сборки получают открытый и секретный ключ, например, генерируют данные открытого и секретного ключей с помощью поставляемой в составе .NET Framework SDK утилиты sn.exe. Эта утилита генерирует файл, который содержит данные для двух разных, но математически связанных ключей - открытого и секретного. После указывают местонахождения этого файла компилятору, который запишет полное значение открытого ключа в манифест сборки.

В частном случае компилятор генерирует на основе всего содержимого сборки (CIL кода, метаданных и т.д.) соответствующий хеш. Хешем является числовое значение, которое является статистически уникальным для фиксированных входных данных. Следовательно, в случае изменения любых данных сборки .NET (даже одного символа в строковом литерале) компилятор выдает другой хеш. Далее полученный хеш объединяется с содержащимися внутри файла данными секретного ключа для получения цифровой подписи, вставляемой в сборку внутрь данных заголовка CLR. На Фиг. 1в показано, как выглядит процесс создания строгого имени.

Данные секретного ключа в манифесте не указываются, а служат только для удостоверения содержимого сборки цифровой подписью (вместе с генерируемым хешем). По завершении процесса создания и назначения строгого имени сборка может устанавливаться в GAC.

Путь к сборке в GAC:

Исполнение кода сборки, в частном случае, происходит следующим образом. В первую очередь происходит анализ заголовка РЕ, чтобы узнать, какой процесс запустить (32 или 64-разрядный). Затем загружается выбранная версия файла .

Пример исходного кода сборки приведен ниже.

Для выполнения метода (для удобства код представлен в исходном виде, а не в скомпилированном в CIL код), например метода System.Console.WriteLine(«Kaspersky»), CIL код ЛТ-компилятор преобразует в машинные команды (Фиг. 2).

В первую очередь перед выполнением функции Main() среда CLR находит все объявленные типы(классы) (например, тип Console). Затем определяет методы, объединяя их в записи внутри единой «структуры» (по одному методу, определенному в типе Console). Записи содержат адреса, по которым можно найти реализации методов. При первом обращение к методу WriteLine вызывается ЛТ-компилятор. ЛТ-компилятору известен вызываемый метод и тип, которым определен этот метод. ЛТ компилятор ищет в метаданных соответствующей сборки реализацию кода метода (код реализации метода WriteLine(string str)). Затем ЛТ компилирует IL в машинный код, сохраняя его в динамической памяти. Далее ЛТ-компилятор возвращается к внутренней «структуре» данных типа (Console) и заменяет адрес вызываемого метода на адрес блока памяти с машинным кодом. После этого метод Main() обращается к методу WriteLine(string str) повторно. Т.к. код уже скомпилирован, обращение без вызова ЛТ-компилятора. Выполнив метод WriteLine(string str) управление возвращается методу Main().

Из описания следует, что «медленно» работает функция только в момент первого вызова, когда ЛТ переводит CIL-код в инструкции процессора. Во всех остальных случаях код уже находится в памяти и подставляется как оптимизированный для данного процессора. Однако, если будет запущена еще одна программа в другом процессе, то ЛТ-компилятор будет вызван снова для того же метода.

Образы, о которых упоминалось выше, решают задачу «медленной работы функции в момент первого вызова». При загрузке сборки будет подгружаться образ, из которого будет исполняться машинный код, благодаря этой технологии возможно ускорение загрузки и запуска приложения в силу того, что ЛТ-компилятору не нужно ничего компилировать, а также каждый раз заново создавать структуры данных(записи), все это берется из образа. Образ можно создать для любой .NET-сборки вне зависимости от того, установлена она в GAC или нет. Для компиляции, в частном случае, используется утилита ngen.exe, располагающаяся по пути .

При запуске ngen.exe происходит создание машинного кода для IL кода сборки с помощью ЛТ-компилятора, результат сохраняется на диск в хранилище образов NIC (Native Image Cache). Компиляция производится на локальном устройстве с учетом его программно-аппаратной конфигурации, поэтому образ должен использоваться только в той среде (окружении), под которую компилировался. Цель создания таких образов - повышение эффективности управляемых приложений, то есть вместо ЛТ-компиляции загружается готовая сборка в машинном коде.

Если код сборки используется многими приложениями, то создание образа значительно увеличивает скорость запуска и работы приложения, так как образ может использоваться одновременно многими приложениями, а код, генерируемый на лету ЛТ-компилятором, используется только тем запущенным экземпляром приложения, для которого он компилируется.

Путь к компилируемому образу формируется следующим образом, например:

При создании образа машинного кода сборки ngen.exe для 64-битных приложений сохраняет данные о нем в ветке реестра для 32-битных приложений в

Если образ устанавливался для сборки, расположенной в GAC, ветка будет называться так:

Если же сборка не была установлена в GAC, то так:

До Windows 8 разработчик всегда должен был сам инициировать создание, обновление и удаление образов сборок, используя ngen.exe (или конфигурируя установщик). Начиная с Windows 8, для некоторых сборок Windows создает образы автоматически.

В частном случае для управления образами используется служба Native Image Service. Она позволяет разработчикам откладывать установку, обновление, удаление образов в машинном коде, выполняя эти процедуры отложенно, когда устройство простаивает. Native Image Service запускают программой установки приложения или обновления. Делается это посредством утилиты ngen.exe. Служба работает с очередью запросов, сохраняемой в реестре Windows, каждый из запросов имеет свой приоритет. От установленного приоритета зависит то, когда будет выполняться задача.

В другом частном случае образы в машинном коде создают не только по инициативе разработчиков или администраторов, но и автоматически платформой .NET Framework. Платформа .NET Framework автоматически создает образ, отслеживая работу ЛТ-компилятора. Создание образа во время работы приложения занимает слишком много времени, поэтому эта операция проводится отложенно, для чего среда CLR ставит задачи в очередь и выполняет их во время простоя устройства.

Среда CLR для поиска сборок для загрузки в момент запуска соответствующей сборки использует модуль связывания сборок (Assemble Binder). CLR использует несколько видов модулей связывания. Для поиска образов используется модуль связывания образов (Native Binder). Поиск нужного образа проводится в два этапа - сначала указанный модуль находит сборку и образ на файловой системе, затем проверяет соответствие образа сборке. Алгоритм поиска представлен на Фиг. 3. На этапе 310 модуль связывания сборок ищет сборку, поиск производится в:

- GAC, что подразумевает, что искомая сборка подписана, содержимое сборки не читается;

- каталоге приложения, сборка открывается и читаются метаданные.

Далее на этапе 320 модуль связывания образов ищет образ в NIC, соответствующий найденной сборке. В том случае, если образ найден, это проверяется на этапе 330, то модуль связывания образов зачитывает необходимые данные и метаданные из образа на этапе 340 и убеждается, что образ подходящий, для чего проводит тщательную проверку, которая в том числе включает контроль:

- строгого имени;

- времени создания (образ должен быть новее, чем сборка);

- MVID сборки и образа;

- версии .NET Framework;

- архитектуры процессора;

- версии связанных образов (например, образ mscorlib.dll);

- и т.д.

Если сборка, для которой ищется образ, не имеет строгого имени, тогда вместо него для проверки используется MVID. В том случае, если образ не актуален, это проверяется на этапе 350, управление передается ЛТ-компилятору на этапе 370, иначе загружается код из образа на этапе 360.

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

Раскрытие изобретения

Настоящее изобретение предназначено для определения категория доверия образов, хранящихся на устройстве.

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

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

В частном случае доступ на запись ограничивают для всех процессов за исключением ngen.exe.

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

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

Краткое описание чертежей

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

Заявленное изобретение поясняется следующими чертежами, на которых:

Фиг. 1а показывает пример однофайловой сборки;

Фиг. 1б показывает пример многофайловой сборки;

Фиг. 1в показывает способ формирования строго имени;

Фиг. 2 показывает способ исполнения кода сборки;

Фиг. 3 показывает способ работы модуля связывания;

Фиг. 4 показывает способ определения категории доверия образа;

Фиг. 5 показывает способ создания шаблона;

Фиг. 6 показывает способ установки образов на устройстве;

Фиг. 7 показывает пример компьютерной системы общего назначения.

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

Описание изобретения

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

На Фиг. 4 изображен способ категоризации образов. На этапе 400 получают образ. Образ в одном частном случае получают из NIC (например, если образ установлен на устройстве и используется на устройстве по назначению), в другом частном случае из любого другого хранилища образов (например, когда устройство используется в качестве хранилища и образы не используются на этом устройстве по назначению). Далее на этапе 410 определяют категорию доверия образа. В частном случае для определения категории доверия образа осуществляют запрос к базе данных, где для запроса используют, например, контрольную сумму образа, в другом частном случае используют MVID образа. Также для определения категории образа используют шаблоны. Механизм работы с шаблонами приводится ниже. Если образ не известен в базе данных, то на этапе 420 определяют родительскую сборку, на основе которой создали образ. Для определения используют по меньшей мере следующие данные, структуры данных и средства:

- MVID;

- реестр;

- модуль связывания;

- строгое имя.

Определение по MVID используют, например, при наличии базы данных, содержащей MVID сборок, имеющихся на устройстве. Для этого определяют MVID образа и обращаются к базе данных, хранящей MVID сборок.

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

Определение родительской сборки по строгому имени используют для образов, созданных из строго именованных сборок. Из образа извлекают компоненты строгого имени родительской сборки, формируют строгое имя и на основании этих данных определяют путь к родительской сборке в GAC на устройстве или в базе данных, хранящей сборки упорядоченно в соответствии со строгим именем.

Выбор способа определения родительской сборки осуществляют в зависимости от ряда факторов. Такими факторами, например, являются: местоположение родительской сборки и образа (устройство пользователя или удаленная либо локальная база данных), возможность компрометации сборки и образа в месте их хранения, способ именования сборки (строгое имя или обычное) и т.д.

В частном случае после определения родительской сборки дополнительно на этапе 421 определяют соответствие между образом и сборкой. Данный этап осуществляют в том случае, если существует вероятность того, что образ после создания мог быть несанкционированно изменен (скомпрометирован) по месту хранения. В одном случае для определения соответствия используют алгоритм, который используется модулем связывания образов, известным из уровня техники, в другом частном случае после определения родительской сборки создается образ от этой сборки (оригинальный образ) и осуществляется непосредственное сравнение оригинального образа с анализируемым образом для определения соответствия, сравнение осуществляют, например, побайтовое.

В частном случае, для того чтобы избежать несанкционированного изменения образов, модификацию образов разрешают только доверенным процессам, например только ngen.exe, другим процессам разрешается только чтение данных из образа.

В некоторых случаях для определения соответствия между образом и родительской сборкой используется механизм шаблонов. В частном случае, если соответствие между родительской сборкой и соответствующим образом отсутствует, образ считается скомпрометированным (вредоносным). Скомпрометированный образ от оригинального образа может отличаться CIL кодом, машинным кодом, метаданными типов, информацией, содержащейся в заголовках CLR и РЕ.

Образ, как и сборка, имеет некоторую структуру, например, которая изображена на Фиг. 5. Сборка KasperskyLab.dll и образ KasperskyLab.ni.dll содержат метаданные и код, где сборка содержит исключительно CIL код, а образ, в частном случае, дополнительно машинный код и структуру NativeImageHeader. На основании структуры, метаданных и кода формируется шаблон KasperskyLab.dll.tmpl, о котором уже упоминалось выше, который однозначно соответствует родительской сборке и созданному на ее основе образу. Для связывания структуры, кода и метаданных в шаблон используют, например, технологию гибкого хеша (англ. intelligent hash, также известный как local sensitive hash). В частном случае шаблон формируют, как показано на Фиг. 5. Из сборки извлекаются данные (манифест, метаданные, CIL код и т.д.). Из образа извлекаются те же данные и дополнительно машинный код. Данные, которые неизменны для каждой из возможных версий образа, созданных от одной родительской сборки, обрабатываются (например, от них рассчитывается контрольная сумма) и формируется хеш, который помещается в шаблон. Данные, которые изменяются от версии к версии образа, например машинный код, также обрабатываются и на основании обработки формируется гибкий хеш. В частном случае, для машинного кода формируют журнал вызова функций, листинг с дизассемблированным машинным кодом или любую другую сущность, которая отражает логику исполнения указанного машинного кода, из этих сущностей и формируют гибкий хеш, в другом частном случае эти сущности используются в шаблоне непосредственно. Следует отметить, что шаблон формируется таким образом, что однозначно связывает (устанавливает соответствие) родительскую сборку и образ независимо от версий образа, зависящих от программно-аппаратной конфигурации устройства. В том случае, если в машинный код образа вносятся изменения и логика исполнения кода образа перестает соответствовать логике исполнения кода сборки, соответствие между родительской сборкой и образом на основании шаблона не устанавливается, образ признается не соответствующим сборке.

Далее описывается пример определения соответствия при помощи шаблона. Например, существует некоторая родительская сборка Kaspersky.dll, для нее на устройстве создается образ Kaspersky.ni.dll. Формируется шаблон Kaspersky.dll.tmpl, который позволяет установить соответствие между родительской сборкой и образом. Далее на устройстве происходит обновление программно-аппаратной части (обновление операционной системы, .NET Framework, замена процессора) и версия образа Kaspersky.ni.dll становится неактуальной, образ использоваться не может, поэтому инициируют обновление этого образа и создают новый образ Kaspersky.ni.dll, который отличен от образа предыдущей версии. Но при использовании шаблона определяют, что обновленный образ соответствует родительской сборке (логика исполнения машинного кода осталась прежней). Пусть в другом случае на устройство устанавливается вредоносное программное обеспечение, которое модифицирует образ Kaspersky.ni.dll. В данном случае при использовании шаблона определяют, что образ, модифицированный вредоносным программным обеспечением, не соответствует родительской сборке (логика исполнения машинного кода отличается от логики, заложенной в родительской сборке).

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

К доверенным сборкам относятся сборки, которые, по мнению системы защиты устройства, являются безопасными. Система защиты устройства, присваивая категорию доверия сборке, делает это локально в рамках текущего состояния на устройстве и на основании информации о сборке. В частном случае, такой информацией является статус опасности сборки. Статус опасности сборки определяют, используя идентификационную информацию сборки, например MVID сборки, строгое имя сборки или контрольную сумму сборки. Для этого организуют запрос к репутационной базе данных на этапе 431, база располагается, в частном случае, на устройстве, на котором хранится сборка, в другом частном случае база располагается удаленно. Если сборка известна (информация о ней содержится в репутационной базе), то, соответственно, сборка уже имеет статус опасности безопасная или опасная в зависимости от того, какой идентификационной информации из репутационной базы соответствует идентификационная информация проверяемой сборки. Если идентификационная информация сборки не содержится в базе данных, сборка считается неизвестной, т.е. сборка не имеет статуса (статус не определен). Если сборка имеет статус безопасной, то в частном случае сборка получает категорию доверенной. В другом частном случае категория сборки определяется исходя из другой фактической и статистической информации о сборке, например по пути установки сборки на устройстве или принадлежности ее к установочным пакетам, статус опасности которых известен.

В частном случае фактической информацией о сборке является информация о цифровой подписи (например, StrongName подписи или Х.509), при этом цифровая подпись должна быть действительна. Для этого на этапе 432 получают идентификационную информацию о цифровой подписи сборки, которая содержит, например, информацию о производителе или хеш файла или его части. При этом подпись может располагаться как в сборке, так и в каталоге (каталожная подпись). Статус опасности цифровой подписи сборки определяют, используя идентификационную информацию подписи, для этого организуют запрос к репутационной базе данных, база располагается в одном частном случае на устройстве, на котором хранится сборка, в другом частном случае база располагается удаленно. Если подпись известна (информация о ней содержится в репутационной базе), то, соответственно, подпись уже имеет статус безопасная или опасная в зависимости от того, какой идентификационной информации из репутационной базы соответствует идентификационная информация проверяемой подписи. Если идентификационная информация подписи не содержится в базе данных, подпись считается неизвестной, т.е. подпись не имеет статуса (статус неизвестен). В частном случае, если подпись имеет статус безопасная, то в частном случае сборка получает категорию доверенная, а если подпись имеет статус опасная, то в частном случае сборка получает категорию недоверенная.

Статусы подписям назначают разными способами, в одном частном случае в зависимости от производителя, в другом частном случае наследованием от установщика, статус подписи которого известен. В некоторых случаях статус подписи назначается в зависимости от популярности подписи, например, чем подпись популярнее, тем больше доверия она вызывает.

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

После определения категории доверия сборки на этапе 440 определяют категорию доверия образа. В частном случае образу назначают категорию доверия определенную для родительской сборки, в другом частном случае категорию образа определяют способом, описанным выше для шага 410.

При установке системы защиты на устройство необходимо гарантировать, что хранилище образов не было несанкционированно изменено и изменено не будет, для этого применяется ряд мер. На Фиг. 6 изображен назначения категории образу. На этапе 600 ограничивают доступ к хранилищу образов или по меньшей мере одному образу, ограничение в частном случае заключается в том, что модифицировать образ разрешают только доверенным процессам или конечному числу некоторых доверенных процессов, например только процессу ngen.exe, всем остальным процессам разрешен только доступ на чтение. В другом частном случае ограничение заключается в полной блокировке доступа на запись к хранилищу в целом или по меньшей мере к одному образу. На этапе 610 определяют родительскую сборку, на основе которой создали образ, доступ к которому ограничили. На этапе 620 запускают обновление (замену) по меньшей мере одного образа. В одном частном случае обновление заключается в удалении ранее созданного образа и создание нового средствами операционной системы (запуском ngen.exe на родительской сборке или сервисом автоматического создания образов), в другом частном случае изменяют лишь часть данных образа, например машинный код, при этом обновление осуществляется доверенными процессами. В первом случае образ после удаления создают вновь, в одном частном случае немедленно, в другом случае создание откладывают на некоторое время, например до запуска родительской сборки, определенной на этапе 610, образ которой подлежит обновлению. На этапе 630 назначают образу категорию родительской сборки.

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

Фиг. 7 представляет пример компьютерной системы общего назначения, персональный компьютер или сервер 20, содержащий центральный процессор 21, системную память 22 и системную шину 23, которая содержит разные системные компоненты, в том числе память, связанную с центральным процессором 21. Системная шина 23 реализована, как любая известная из уровня техники шинная структура, содержащая в свою очередь память шины или контроллер памяти шины, периферийную шину и локальную шину, которая способна взаимодействовать с любой другой шинной архитектурой. Системная память содержит постоянное запоминающее устройство (ПЗУ) 24, память с произвольным доступом (ОЗУ) 25. Основная система ввода/вывода (BIOS) 26 содержит основные процедуры, которые обеспечивают передачу информации между элементами персонального компьютера 20, например, в момент загрузки операционной системы с использованием ПЗУ 24.

Персональный компьютер 20 в свою очередь содержит жесткий диск 27 для чтения и записи данных, привод магнитных дисков 28 для чтения и записи на сменные магнитные диски 29 и оптический привод 30 для чтения и записи на сменные оптические диски 31, такие как CD-ROM, DVD-ROM и иные оптические носители информации. Жесткий диск 27, привод магнитных дисков 28, оптический привод 30 соединены с системной шиной 23 через интерфейс жесткого диска 32, интерфейс магнитных дисков 33 и интерфейс оптического привода 34 соответственно. Приводы и соответствующие компьютерные носители информации представляют собой энергонезависимые средства хранения компьютерных инструкций, структур данных, программных модулей и прочих данных персонального компьютера 20.

Настоящее описание раскрывает реализацию системы, которая использует жесткий диск 27, сменный магнитный диск 29 и сменный оптический диск 31, но следует понимать, что возможно применение иных типов компьютерных носителей информации 56, которые способны хранить данные в доступной для чтения компьютером форме (твердотельные накопители, флеш-карты памяти, цифровые диски, память с произвольным доступом (ОЗУ) и т.п.), которые подключены к системной шине 23 через контроллер 55.

Компьютер 20 имеет файловую систему 36, где хранятся записанная операционная система 35, а также дополнительные программные приложения 37, другие программные модули 38 и данные программ 39. Пользователь имеет возможность вводить команды и информацию в персональный компьютер 20 посредством устройств ввода (клавиатуры 40, манипулятора «мышь» 42). Могут использоваться другие устройства ввода (не отображены): микрофон, джойстик, игровая консоль, сканнер и т.п. Подобные устройства ввода по своему обычаю подключают к компьютерной системе 20 через последовательный порт 46, который в свою очередь подсоединен к системной шине, но могут быть подключены иным способом, например при помощи параллельного порта, игрового порта или универсальной последовательной шины (USB). Монитор 47 или иной тип устройства отображения также подсоединен к системной шине 23 через интерфейс, такой как видеоадаптер 48. В дополнение к монитору 47 персональный компьютер может быть оснащен другими периферийными устройствами вывода (не отображены), например колонками, принтером и т.п.

Персональный компьютер 20 способен работать в сетевом окружении, при этом используется сетевое соединение с другим или несколькими удаленными компьютерами 49. Удаленный компьютер или компьютеры 49 являются такими же персональными компьютерами или серверами, которые имеют большинство или все упомянутые элементы, отмеченные ранее при описании сущности персонального компьютера 20, представленного на Фиг. 7. В вычислительной сети могут присутствовать также и другие устройства, например маршрутизаторы, сетевые станции, пиринговые устройства или иные сетевые узлы.

Сетевые соединения могут образовывать локальную вычислительную сеть (LAN) 50 и глобальную вычислительную сеть (WAN). Такие сети применяются в корпоративных компьютерных сетях, внутренних сетях компаний и, как правило, имеют доступ к сети Интернет. В LAN- или WAN-сетях персональный компьютер 20 подключен к локальной сети 50 через сетевой адаптер или сетевой интерфейс 51. При использовании сетей персональный компьютер 20 может использовать модем 54 или иные средства обеспечения связи с глобальной вычислительной сетью, такой как Интернет. Модем 54, который является внутренним или внешним устройством, подключен к системной шине 23 посредством последовательного порта 46. Следует уточнить, что сетевые соединения являются лишь примерными и не обязаны отображать точную конфигурацию сети, т.е. в действительности существуют иные способы установления соединения техническими средствами связи одного компьютера с другим.

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

1. Способ ограничения доступа образа машинного кода к ресурсам, предоставляемым операционной системой, в котором:

а) ограничивают доступ на запись к по меньшей мере одному образу машинного кода;

б) определяют родительскую сборку, где родительской сборкой является сборка, на основании которой создан образ, доступ на запись к которому ограничен;

в) заменяют образ, доступ к которому ограничен, образом, созданным на основании определенной родительской сборки;

г) определяют категорию доверия определенной родительской сборки;

д) назначают категорию доверия, определенную для родительской сборки обновленному образу машинного кода;

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

2. Способ по п. 1, в котором доступ на запись ограничивают для всех процессов за исключением ngen.exe.

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

4. Способ по п. 1, в котором замена образа машинного кода осуществляется путем удаления образа, доступ на запись к которому ограничен, и создания нового образа машинного кода от определенной родительской сборки средствами операционной системы.



 

Похожие патенты:

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

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

Изобретение относится к защите от несанкционированного доступа к информации при ее передаче по каналам связи. Технический результат – повышение пропускной способности средств защиты информации.
Изобретение относится к области обнаружения скрытого программного обеспечения в вычислительных системах, работающих под управлением POSIX-совместимых операционных систем, например Solaris, Android и др.

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

Изобретение относится к защите от несанкционированного доступа к информации. Технический результат - обеспечение одновременной обработки информации с разными уровнями конфиденциальности в двух соответствующих ЭВМ с использованием одного набора устройств для взаимодействия с пользователем и для доступа к разделяемым внешним носителям.

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

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

Изобретение относится к компьютерной безопасности. Технический результат заключается в обеспечении совместимости загрузочного диска с новой версией модуля полнодискового шифрования.

Изобретение относится к компьютерной безопасности. Технический результат заключается в сокращении количества антивирусных записей на компьютерах пользователей, использование которых антивирусным приложением вызывает ложные срабатывания. Предложен способ управления антивирусными записями на множестве компьютеров пользователей, в котором в течение заданного времени собирают параметры антивирусной записи со статусом «рабочая» при ее срабатывании на компьютерах пользователей; собирают статистику срабатывания антивирусной записи и определяют общее количество компьютеров пользователей, на которых сработала антивирусная запись; с использованием параметров антивирусной записи и статистики срабатывания антивирусной записи определяют принадлежность антивирусной записи к классу антивирусных записей, использование которых вызывает ложное срабатывание, если определенное общее количество компьютеров пользователей превышает заданное пороговое значение; изменяют статус антивирусной записи с «рабочей» на «тестовую» и отправляют антивирусному приложению, установленному на компьютерах пользователей, измененный статус антивирусной записи. 2 н. и 28 з.п. ф-лы, 9 ил.

Изобретение относится к области управления полномочиями. Технический результат – снижение вычислительной нагрузки, связанной с предотвращением модификации конфигураций терминала неавторизованным пользователем. Способ управления полномочиями, включающий: получение информации об отпечатке пальца пользователя на основе операции касания пользователем области заранее заданного интерфейса терминала; определение, является ли пользователь авторизованным пользователем, в соответствии с полученной информацией об отпечатке пальца; и, если пользователь является неавторизованным пользователем, запрет предоставления полномочий для модификации конфигураций терминала пользователем; при этом операция касания включает операцию длительного нажатия; процедура получения информации об отпечатке пальца пользователя на основе операции касания экрана пользователем области заранее заданного интерфейса терминала включает: контроль событий касания пользователем области заранее заданного интерфейса терминала; определение, является ли контролируемое событие касания событием длительного нажатия; и, если контролируемое событие касания является событием длительного нажатия, получение информации о координате касания в процессе события длительного нажатия и информации об отпечатке пальца пользователя в позиции координаты касания. 3 н. и 10 з.п. ф-лы, 10 ил.

Изобретение относится к системе и устройству обработки информации. Технический результат заключается в повышении безопасности при использовании системы обработки информации из терминала. Устройство обработки информации накапливает задания, принятые от оконечного устройства; получает информацию о пользователе, которая идентифицирует пользователя оконечного устройства, и первую идентификационную информацию, сохраненную в устройстве хранения идентификационной информации оконечного устройства, которая идентифицирует оконечное устройство; определяет, соответствует ли первая идентификационная информация второй идентификационной информации, причем вторая идентификационная информация включена в первое задание, принятое и накопленное посредством устройства обработки информации, при этом вторая идентификационная информация идентифицирует оконечное устройство, которое отправило первое задание на устройство обработки информации, а первое задание включает в себя другую информацию о пользователе, которая соответствует полученной информации о пользователе; и исполняет первое задание, если первая идентификационная информация соответствует второй идентификационной информации. 4 н. и 7 з.п. ф-лы, 25 ил.

Настоящее изобретение относится к устройству управления доступом к компьютерной системе, устройство содержит по меньшей мере один многофункциональный порт (Ui), который может быть соединен с различными категориями периферийных устройств, и интерфейс доступа (INT), который может быть соединен с компьютерной системой, при этом устройство содержит средство управления доступом (Масс), соединенное между многофункциональным портом (Ui) и интерфейсом (INT), указанное средство управления доступом физически выполнено с возможностью авторизации доступа к интерфейсу со стороны периферийного устройства (Р), соединенного с многофункциональным портом (Ui), только если указанное периферийное устройство принадлежит к категории периферийных устройств, индивидуально и постоянно ассоциированной с многофункциональным портом (Ui), соединенным с периферийным устройством. Настоящее устройство относится к соответствующему способу управления доступом. 3 н. и 10 з.п. ф-лы, 5 ил.

Изобретение относится к устройству обработки информации преимущественно в игровом автомате. Технический результат – обеспечение возможности регистрации нескольких пользователей с возможностью получения каждым из них награды. Изобретение содержит секцию 102 связи, устройство 10 обработки информации, секцию 150 хранения информации о зарегистрированных пользователях для хранения биометрической информации пользователя, зарегистрированную в устройстве 10 обработки информации, участок 140 биометрической аутентификации, секцию 150 хранения информации зарегистрированных пользователей для определения, является ли пользователь, изображение которого получено, пользователем, зарегистрированным в устройстве 10 обработки информации. После определения, что пользователь, изображение которого получено, является пользователем, зарегистрированным в устройстве 10 обработки информации, контроллер 120 входа в систему выполняет процесс входа пользователя в систему или, более конкретно, сохраняет информацию для идентификации устройства, содержащегося в полученном изображении, и информацию для идентификации пользователя в участок 142 хранения информации для входа пользователей в систему, связывая эти элементы информации друг с другом. 4 н. и 4 з.п. ф-лы, 11 ил.

Изобретение относится к области защиты от компьютерных угроз, а именно к способам обнаружения мошеннической активности на устройстве пользователя. Технический результат настоящего изобретения заключается в защите удаленного банковского сервера от мошеннической активности, которая достигается путем блокирования взаимодействия устройства пользователя с удаленным банковским сервером, если была обнаружена мошенническая активность во время взаимодействия устройства пользователя с удаленным банковским сервером. Способ обнаружения мошеннической активности на устройстве пользователя при взаимодействии вычислительного устройства пользователя с удаленным банковским сервером содержит этапы, на которых: a) собирают при помощи средства определения поведения данные о поведении пользователя во время взаимодействия пользователя с по меньшей мере одной группой элементов графического интерфейса приложения, которые используются для взаимодействия с удаленным банковским сервером; при этом целью взаимодействия с удаленным банковским сервером является осуществление транзакции с участием удаленного банковского сервера; при этом данными о поведении пользователя является информация, которую получают при помощи по меньшей мере устройств ввода вычислительного устройства; b) вычисляют при помощи средства классификации поведения коэффициент аномальности поведения пользователя для каждой группы элементов графического интерфейса, данные о поведении пользователя во время взаимодействия с которой были собраны на этапе ранее; при этом коэффициент аномальности поведения пользователя представляет собой численное значение, чем больше которое, тем менее характерно поведение, данные о котором были собраны на этапе ранее, упомянутому пользователю; с) обнаруживают при помощи средства принятия решения мошенническую активность при взаимодействии устройства пользователя с удаленным банковским сервером, если комбинация коэффициентов аномальности поведения пользователя, вычисленных на этапе ранее, не превышает установленное пороговое значение; d) блокируют при помощи средства принятия решения взаимодействие устройства пользователя с удаленным банковским сервером, если была обнаружена мошенническая активность при взаимодействии устройства пользователя с удаленным банковским сервером. 1 з.п. ф-лы, 4 ил.

Изобретение относится к области обработки данных, более конкретно к специализированным связным программируемым вычислительным системам с распараллеливанием и конвейеризации вычислительных процессов. Технический результат заключается в увеличении адаптивности к условиям применения и масштабируемости функциональных ресурсов программно-аппаратной платформы. Указанный результат обеспечивается конструктивным исполнением в «системе-на-кристалле» (СнК), включающей в себя CPU, доверенную цифровую технологическую платформу SDR, шину I/O, DSP сопроцессор, конструктивно выполненные в СнК, защищенное ПЗУ с микроконтроллером, ОЗУ, машиночитаемый носитель, периферийные устройства ввода-вывода и программного компонента, включающего доверенный БИОС, доверенную виртуальную среду, управляющие, сервисные и прикладные виртуальные машины и гипервизор, сервисное ПО, прикладное ПО с зонами доверенных и недоверенных ВМ, в которых доверенный БИОС соединен с определяющей взаимодействие ДВС, которая через управляющие, сервисные и прикладные виртуальные машины связана с сервисными ПО и прикладными ПО. 2 н. и 6 з.п. ф-лы, 1 ил.

Изобретение относится к обработке контента для приложений. Технический результат заключается в уменьшении вероятности доступа вредоносного кода к чувствительным частям вычислительного устройства. Предложена компьютерная система, в которой принимают указание того, что часть приложения запрашивает передачу контента в элемент кода вычислительного устройства, приложение включает в себя первый раздел и второй раздел; устанавливают на основе идентификатора для части приложения, является ли данная часть частью первого раздела, которому разрешен доступ к критически важным функциональным возможностям вычислительного устройства, или частью второго раздела, которому не разрешен доступ к данным функциональным возможностям, при этом первый и второй разделы имеют первый и второй набор политик обработки контента соответственно; применяют один из первого или второго наборов политик обработки контента к упомянутому запросу на основе того, является ли часть приложения частью первого раздела или второго раздела, причем данной части приложения разрешается или не разрешается передавать контент в элемент кода в соответствии с одним из первого или второго набора политик обработки контента. 3 н. и 17 з.п. ф-лы, 6 ил.

Изобретение относится к области управления техническими устройствами, которые принадлежат области компьютерных технологий. Технический результат – повышение безопасности управления при удаленном доступе к интеллектуальным устройствам. Способ управления интеллектуальным устройством, который применяют в интеллектуальном модуле, размещенном в интеллектуальном устройстве, включающий: широковещательную передачу идентификационной информации интеллектуального модуля для приема терминалом упомянутой идентификационной информации и для передачи идентификационной информации и учетной записи пользователя на сервер для того, чтобы сервер связал идентификационную информацию с учетной записью пользователя, сформировал данные подписи, передал данные подписи в терминал и передал учетную запись пользователя в интеллектуальный модуль; прием учетной записи пользователя, переданной сервером; прием данных управления, переданных терминалом, при этом данные управления содержат управляющую инструкцию и данные подписи, где данные подписи переданы сервером в терминал и получены сервером путем вычисления с использованием ключа интеллектуального модуля и учетной записи пользователя, соответствующей терминалу, согласно заранее заданному алгоритму; проверку данных подписи, при этом проверка данных подписи включает: считывание учетной записи пользователя, заранее сохраненной в интеллектуальном модуле, и считывание ключа, заранее записанного сервером в интеллектуальный модуль; выполнение вычисления с использованием учетной записи пользователя и ключа согласно заранее заданному алгоритму для получения данных проверки; обнаружение, являются ли данные проверки идентичными данным подписи; и когда данные проверки идентичны данным подписи, определение того, что данные подписи прошли проверку; и если проверка пройдена, обеспечение выполнения, интеллектуальным устройством, операции, соответствующей управляющей инструкции. 3 н.п. ф-лы, 11 ил.

Изобретение относится к области вычислительной техники. Технический результат – повышение надежности и защищенности информации от несанкционированного доступа. Способ включает идентификацию пользователя сети порталов по активному сеансу и проведение проверки подлинности для неидентифицированных пользователей посредством одного из узлов доступа защищенной виртуальной среды по наличию атрибутов сеанса пользователя, представленных идентификатором пользовательского сеанса и факторами прохождения аутентификации, подписанными центральным узлом либо резервным центральным узлом. А аутентификационные данные пользователей хранят только на сервере LDAP центрального узла и сервере LDAP центрального резервного узла защищенной виртуальной среды. Запрос для доступа к информационно-вычислительному ресурсу обрабатывает один из узлов доступа защищенной виртуальной среды, который производит проверку подлинности сеанса пользователя на центральном узле, в результате успешной проверки подлинности сеанса пользователя клиентского ПК центральный узел в виде ответа на запрос направляет на узел доступа атрибуты сеанса пользователя, которые узел доступа сначала сохраняет на сервере LDAP узла доступа. Затем узел доступа проводит проверку привилегированности доступа пользователя к запрашиваемым данным информационно-вычислительного ресурса и в результате успешной проверки предоставляет к ним доступ. А в случае запроса пользователя к другому информационно-вычислительному ресурсу проверку подлинности сеанса пользователя производят путем проверки атрибутов сеансовых данных, хранимых на сервере LDAP узла доступа. 5 ил.

Изобретение относится к области категоризации образов сборок. Техническим результатом является повышение безопасности устройства путем ограничения доступа образа машинного кода, имеющего категорию доверия недоверенный, к ресурсам, предоставляемым операционной системой. Способ ограничения доступа образа машинного кода к ресурсам, предоставляемым операционной системой, в котором: а) ограничивают доступ на запись к по меньшей мере одному образу машинного кода; б) определяют родительскую сборку, где родительской сборкой является сборка, на основании которой создан образ, доступ на запись к которому ограничен; в) заменяют образ, доступ к которому ограничен, образом, созданным на основании определенной родительской сборки; г) определяют категорию доверия определенной родительской сборки; д) назначают категорию доверия, определенную для родительской сборки обновленному образу машинного кода; е) ограничивают доступ образа машинного кода, имеющего категорию доверия недоверенный, к ресурсам, предоставляемым операционной системой. 3 з.п. ф-лы, 9 ил.

Наверх