СПОСОБ И УСТРОЙСТВО ДЛЯ ПРОВЕРКИ ИСПОЛНЯЕМОЙ ПРОГРАММЫ С ИСПОЛЬЗОВАНИЕМ МОДЕЛИ

Область техники, к которой относится изобретение

Данное изобретение относится, в общем, к проверке исполняемой программы относительно нежелательных режимов работы.

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

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

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

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

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

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

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

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

Фиг. 3 является блок-схемой, сконфигурированной в соответствии с различными вариантами осуществления изобретения; и

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

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

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

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

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

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

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

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

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

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

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

Не отправлять сообщения после того, как файлы считаны.

Не выполнять запись в некоторые/все файлы.

Не выполнять запись в файлы, помимо stdout.

Не пытаться создавать каталог.

Не выполнять считывание из файла X.

Не открывать более X файлов.

Удалять только файлы, которые создаются посредством самого приложения.

Не разветвлять оболочку.

Не исполнять другую (или конкретную) программу.

Не создавать файлы, за исключением /tmp.dir.

Не осуществлять доступ к указываемому пользователями каталогу.

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

Не осуществлять доступ к службе коротких сообщений (SMS).

Не осуществлять доступ к службе мультимедийных сообщений (MMS).

Не осуществлять доступ к DIAL-службе.

Не осуществлять доступ к требующим аккумуляторного питания ресурсам вне конкретного указанного предела.

Не осуществлять доступ к каталогу, который содержит данные об адресной книге.

Не осуществлять доступ к Bluetooth-службе.

Не выделять объем памяти сверх X.

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

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

Посредством одного подхода, эта технология оценки может повторяться один раз, два раза или любое число раз (с использованием идентичного или различного входного содержимого), чтобы тем самым тестировать режим работы программы различными способами и исследовать варьирующиеся тракты через схему исполнения. (При использовании в данном документе эта ссылка на "тракты" должна пониматься как означающая последовательность вызовов операционной системы). Число циклов исполнения, наблюдаемых в приведенном примере, может быть фиксированным или, если требуется, может варьироваться. Например, число циклов исполнения может варьироваться произвольно в некотором предварительно определенном диапазоне, представляющем минимальное число циклов (к примеру, 10) и максимальное число циклов (к примеру, 1000000). В качестве другого подхода в этом отношении, временные пределы могут быть использованы для того, чтобы управлять этой активностью. Например, один временной предел может налагаться для каждого цикла исполнения, и другой временной предел (к примеру, пять минут) может применяться относительно завершенного процесса. Такой подход может служить для того, чтобы не допускать сложностей, которые могут возникать, если данный цикл исполнения переходит в бесконечный цикл. С другой стороны, соответствующие вызовы операционной системы могут отслеживаться и записываться, чтобы дополнительно разрабатывать и расширять возможности модели исполняемой программы.

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

Как указано выше, разработка модели может основываться на динамически и автоматически предоставляемом вводе в программу по мере того, как она исполняется. Технология, к примеру, исполнение concolic может использоваться для того, чтобы поддерживать этот подход. Исполнение Concolic, здесь, использует решающий модуль по ограничениям, к примеру, STP Стэнфорда, чтобы формировать значения, чтобы предоставлять в качестве входных переменных программы (которые, как указано выше, могут содержать случайные вводы), чтобы тем самым исследовать различные тракты программы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сетевой интерфейс 303, в свою очередь, функционально связан с одной или более сетей 304 (к примеру, но не только, с Интернетом через прямой или косвенный путь). При такой конфигурации, сетевой инфраструктурный элемент 300 может быть функционально связан с платформами 305 конечных пользователей или одним или более источников исполняемых программ 306 через эти сети 304, чтобы упрощать различную связь и обмен данными, описанные в данном документе. Различные сети и архитектурные компоновки очень хорошо известны в данной области техники. Поскольку эти идеи не являются слишком чувствительными к конкретным вариантам выбора в этом отношении, для краткости и ясности, дополнительное уточнение в этом отношении не представляется в данном документе.

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

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

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

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

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

Сетевой инфраструктурный элемент затем разрабатывает 403 модель, как описано в данном документе (с использованием этой загруженной исполняемой программы), и проверяет 404 эту модель на предмет политик платформы конечного пользователя. Когда эта проверка приводит к недопустимым результатам, сетевой инфраструктурный элемент может предпринимать одно или более действий (не показаны), чтобы отклонять или иным образом препятствовать загрузке программы посредством платформы конечного пользователя.

Когда процесс 404 проверки приводит к приемлемым результатам в этом иллюстративном примере, сетевой инфраструктурный элемент разрабатывает 405 усеченную версию модели и затем предоставляет эту усеченную модель и соответствующее сообщение 406 подтверждения в первую платформу конечного пользователя. Первая платформа конечного пользователя, в свою очередь, затем использует 407 эту усеченную модель, чтобы проверять все оставшиеся политики, которые представляют интерес для платформы конечного пользователя в этом отношении, и к которым еще не осуществлен доступ посредством сетевого инфраструктурного элемента. Когда этот второй процесс проверки снова дает в результате успешные результаты, первая платформа конечного пользователя затем загружает исполняемую программу 408 согласно исходному намерению и цели.

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

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

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