Безопасность в Longhorn: сосредоточьтесь на минимальных привилегиях

 

Кит Браун
DevelopMentor

Апрель 2004 г.

Область применения:
   Предварительная сборка Longhorn конференции профессиональных разработчиков (PDC) 2003 г.

Сводка: Longhorn обещает быть отличной платформой для приложений с минимальными привилегиями. Начните уже сегодня, написав управляемый код, прежде всего. При создании классических приложений сделайте их совместимыми с LUA (и используйте средство проверки приложений Windows, чтобы проверка работу). (11 печатных страниц)

Содержимое

Проблема
Манифесты приложения и развертывания
LUA: учетная запись пользователя с минимальными привилегиями
Группа (нерекомендуемые) опытные пользователи
AIM: Управление воздействием на приложения
PA: защищенный администратор
Управляемые приложения в Longhorn
Набор разрешений "Без риска"
Инструменты
Сводка

Я уже давно сторонник бега с наименьшими привилегиями. Многие, кто знает меня, слышали мои слова о том, что разработчики должны прекратить работу с правами администратора во время разработки кода, хотя бы для того, чтобы помочь вам написать больше приложений для запуска в средах с минимальными привилегиями. Поэтому я был очень рад услышать на Конференции профессиональных разработчиков Майкрософт (PDC) 2003 года, что одной из main целей следующей версии операционной системы Windows® с кодовым названием Longhorn является упрощение работы пользователей с минимальными привилегиями.

Проблема

Когда вы покупаете копию Microsoft Windows XP® Professional в локальном магазине программного обеспечения и устанавливаете ее на компьютере, мастер установки создает учетные записи для вас и всех, кто будет использовать компьютер. После загрузки Windows XP отображается довольно экран приветствия, на котором отображается имя каждого пользователя и позволяет им войти в систему. Каждый из этих пользователей по умолчанию является администратором компьютера. Почему? Потому что взаимодействие с пользователем было бы плохим, если бы не так.

Пользователи должны иметь возможность устанавливать программное обеспечение на своих компьютерах, но вы не можете установить 90 процентов сегодняшнего программного обеспечения, если вы не являетесь администратором. Пользователи ожидают, что программное обеспечение будет работать без сбоя, но 70 процентов программного обеспечения не будут работать должным образом, если пользователь не является администратором, и это оптимистичный показатель. К сожалению, большое количество этих приложений завершается сбоем в неадминистрированием просто потому, что они плохо делают выбор в отношении того, где сохранить состояние приложения. Каталог Program Files не предназначен для хранения состояния. Это место для хранения программ — исполняемых файлов. Место для хранения состояния приложения называется профилем пользователя, а для хранения общего пользовательского состояния достаточно профиля "Все пользователи". Это объясняется в рекомендациях по программе с логотипом Windows, но сегодня подавляющее большинство программного обеспечения Windows разрабатывается без учета рекомендаций по использованию логотипа Windows.

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

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

Манифесты приложения и развертывания

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

Чтобы узнать больше об этих манифестах, ознакомьтесь с главой 1 книги Брента Проректора Введение "Longhorn" для разработчиков.

LUA: учетная запись пользователя Least-Privilege

LUA, или учетная запись пользователя с минимальными привилегиями, является аббревиатурой Я уверен, что вы будете видеть повторяющиеся снова и снова в презентациях Майкрософт с этого момента. Выступающие PDC 2003 часто произносит акроним как "looah". Это ничего причудливого, даже ничего действительно нового. LUA относится к практике использования учетных записей пользователей без привилегий, как для интерактивных пользователей, так и для служб.

Команда Longhorn хочет упростить безопасность. Они считают, что должно быть два уровня доступа к системе: минимальные привилегии и административный. Они даже не рекомендуют группу "Опытные пользователи" (в некоторых кругах она называется "admin-lite") в Longhorn.

Когда группа "Опытные пользователи" исчезла, разработчикам приложений действительно нужно сделать выбор. Они должны решить, какой из двух уровней привилегий (LUA или административный) требуется приложению для Longhorn. Если приложению не требуются права администратора, его следует тщательно написать для работы с учетной записью с минимальными привилегиями. Это означает тестирование (и, как надеется, даже написание кода) с использованием обычных учетных записей пользователей. Например, приложение LUA должно записывать файлы данных в безопасном месте, например в профиле пользователя, а не в дереве каталога Program Files. Но что происходит с приложениями, которые не переписываются для Longhorn? Что делать, если эти приложения не работают хорошо при учетных записях с минимальными привилегиями даже в Windows XP? Функция Longhorn под названием Управление влиянием приложений (AIM) в любом случае может помочь этим приложениям работать в LUA, как вы увидите в ближайшее время.

Группа (нерекомендуемые) опытные пользователи

Если вы думаете, что учетная запись администратора имеет "высокий" доступ, а обычная учетная запись пользователя с "низким" доступом, можно сказать, что у учетной записи Power User есть "средний" доступ. Группе "Опытные пользователи" разрешено считывать и записывать части файловой системы и реестра, которые обычно недоступны для учетных записей с минимальными привилегиями (то есть обычных учетных записей пользователей, которые не имеют членства в привилегированных группах, таких как администраторы или опытные пользователи). Многие люди, которые пытались работать как обычные пользователи обнаружили, что так много программного обеспечения не удалось, что они решили добавить свои учетные записи в группу Power Users, которая исправила почти все проблемы, которые у них были. Но они не были действительно работает с наименьшими привилегиями больше. Например, в Windows XP любой вредоносной программе, которая запускается с этим средним уровнем привилегий, будет разрешено компрометировать другие приложения, хранящиеся в каталоге Program Files, заменять доверенные com-компоненты троянами и т. д. При следующем запуске пользователя под учетной записью администратора на таком скомпрометированном компьютере вы можете быть уверены, что вредоносная программа также будет запускаться через ранее установленный троян. Поэтому вы не получаете никакой реальной защиты, работающей как опытный пользователь.

AIM: Управление воздействием на приложения

Команда Longhorn считает, что работать с минимальными привилегиями важно. Они хотят, чтобы этот экран приветствия содержал список учетных записей пользователей, которые в основном состоят из учетных записей с минимальными привилегиями. Но они также имеют свои ноги заземленными в реальности. Так же, как многие основные программы сегодня полностью игнорируют программу логотипа Windows, многие основные программы в период longhorn также могут игнорировать инициативу LUA. Неосведомленные разработчики приложений будут продолжать писать программное обеспечение, которое считывает и записывает файлы данных из дерева каталогов Program Files. Они также продолжат записывать данные реестра в HKEY_LOCAL_MACHINE вместо HKEY_CURRENT_USER. Первая из них не ограничена для записи обычными пользователями, поэтому вторая предпочтительнее для хранения параметров приложения, если реестр должен использоваться вообще.

Когда Windows XP обнаруживает, что приложению требуется больше привилегий (это редко, но иногда случается с программами установки), пользователь, не имеющий привилегий, сообщает, что приложению требуются права администратора для запуска, и удобно открывает диалоговое окно для сбора имени пользователя и пароля учетной записи администратора. Затем программа запускается под указанной учетной записью. Но это не всегда работает, так как многие приложения не записываются для установки под одной учетной записью и используются под другой.

Лонгхорн использует совершенно другой подход. Вместо того, чтобы поощрять пользователя к повышению привилегий для правильной работы приложения, Longhorn предпочитает запускать приложение в LUA. Но что происходит, когда приложение пытается выполнить запись в HKEY_LOCAL_MACHINE или в дереве каталогов Program Files? Longhorn предоставляет приложению собственное виртуализированное представление ресурса, который оно пытается изменить, используя стратегию копирования при записи. Когда приложение пытается выполнить запись в файл в каталоге Program Files, Longhorn предоставит приложению собственную частную копию файла и сможет использовать его. Таким образом, любая вредоносная программа, которая теряется в сценарии AIM, может попытаться перезаписать часто используемый исполняемый файл в дереве каталогов Program Files, возможно, WINWORD.EXE. Но то, что он в конечном итоге перезаписывает это частная копия, которую может видеть только вредоносная программа. Версия WINWORD.EXE, который видит пользователь, по-прежнему будет исходной, неоткраченной версией.

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

PA: защищенный администратор

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

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

Пользователь, который обычно работает от имени администратора, открывает свой почтовый клиент Longhorn и начинает просматривать электронную почту. Она наткнулась на кусок почты, который пришел от кого-то, кого она знает, и открывает вложение. Мало ли она знает, что ее подруга недавно была заражена червем электронной почты, и это сообщение содержит вредоносные программы. Когда вредоносная программа запускается, она обнаруживает, что у нее очень мало привилегий в системе. Он не может изменить ничего в дереве каталогов Program Files. Он не может изменить регистрацию COM-объектов в HKEY_LOCAL_MACHINE. Это не значит, что он не может сделать ничего плохого, но ситуация чертовше гораздо лучше, чем было бы, если бы вредоносная программа оказалась запущенной с правами администратора.

Но подождите, разве я не сказал, что пользователь работал от имени администратора при запуске приложения электронной почты? Да, это было на самом деле так. Но приложение электронной почты не было назначено как "благословенное" административное приложение; на самом деле он был написан как приложение LUA. Таким образом, он получил ограниченный маркер, а также вредоносная программа в результате. Это вся суть минимальных привилегий. Если вы потеряете контроль над системой (возможно, потому, что вы случайно запустили какое-то злое программное обеспечение, или, возможно, потому, что вы просто щелкнули неправильный пункт меню), ущерб будет ограничен или, возможно, полностью предотвращен.

Некоторые администраторы, сознающие безопасность, уже реализуют эту политику сегодня. Я одна из них. У меня есть две учетной записи: обычная и административная. Я вхожу как обычный пользователь и иногда переключаюсь на свою учетную запись администратора, когда мне нужно каким-то образом администрировать систему, например добавить виртуальный каталог на компьютере, создать базу данных в Microsoft SQL™ Server и т. д. (В случае, если вам было интересно, я в конечном итоге тратить около 95 процентов моего времени работает как обычный пользователь, даже при разработке программного обеспечения.) Команда Longhorn формализовала этот подход. Идея часто называется "право привилегий в нужное время" в функции защищенного администратора (PA для краткости). Это означает, что я могу работать как администратор все время, но по-прежнему работать с минимальными привилегиями. Больше нет переключения взад и вперед, жонглирования двумя профилями пользователей и т. д.

Если это звучит как аккуратная идея, и вы хотите помочь людям на самом деле использовать эту функцию, вам потребуется серьезно приступить к написанию приложений, которые работают с минимальными привилегиями. Так как если эта функция включена, приложение, которому требуется больше привилегий, чем требуется на самом деле, будет работать без необходимости, даже если администратор запускает его, если только оно не назначено как доверенное приложение администратора. Конечно, AIM может прийти на помощь, но вы не должны полагаться на него, так как корпорация Майкрософт подсчитывает, что 20 процентов приложений, вероятно, не смогут быть совместимы с LUA с помощью AIM. Если вы упадете на эти 20 процентов, приложение не будет запущено. Если этого будет достаточно, никто не будет использовать функцию Защищенного Администратор, и это было бы очень грустно действительно.

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

Управляемые приложения в Longhorn

Одно из сообщений PDC 2003 было о том, что управляемые приложения имеют будущее. Написав управляемый код, вы сможете воспользоваться преимуществами последней революции в области безопасности на платформе Windows: безопасность с помощью удостоверения кода. Система безопасности на основе доказательств, предоставляемая средой CLR и часто называемая безопасностью CAS или "доступом к коду", позволяет среде CLR накладывать дополнительные ограничения на код в зависимости от того, откуда он получен, кто его подписал и т. д. Это дополнительное измерение безопасности открывает новые возможности для распространения программного обеспечения. Выполняя код в безопасной песочнице, клиенты теперь могут уверенно выполнять код, скачанный с центрального сервера, что делает возможными такие функции, как "без касания" и "щелкнуть один раз", что еще больше сокращает расходы на администрирование. И кто не предпочел бы реальное приложение Windows, работающее на своем компьютере, браузерному приложению, если развертывание и угрозы безопасности были похожи?

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

Листинг кода 1. Манифест приложения

<?xml version="1.0" encoding="utf-8"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" 
manifestVersion="1.0" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="urn:schemas-microsoft-com:asm.v1 
assembly.adaptive.xsd">
  <assemblyIdentity name="MyLonghornApp" version="1.0.0.0" 
processorArchitecture="x86" asmv2:culture="en-us" 
publicKeyToken="0000000000000000" />
  <entryPoint name="main" xmlns="urn:schemas-microsoft-com:asm.v2" 
dependencyName="MyLonhornApp">
    <commandLine file="MyLonghornApp.exe" parameters="" />
  </entryPoint>
  <description asmv2:iconFile="App.ico" />
  <TrustInfo xmlns="urn:schemas-microsoft-com:asm.v2" 
xmlns:temp="temporary">
    <Security>
      <ApplicationRequestMinimum>
        <PermissionSet class="System.Security.PermissionSet" 
version="1" ID="SeeDefinition">
          <IPermission 
class="System.Security.Permissions.FileDialogPermission" version="1" 
Unrestricted="true" />
          <IPermission class="System.Security.Permissions.IsolatedStorageFilePermission" 
version="1" Allowed="DomainIsolationByUser" UserQuota="5242880" />
          <IPermission 
class="System.Security.Permissions.SecurityPermission" version="1" 
Flags="Execution" />
          <IPermission class="System.Security.Permissions.UIPermission" 
version="1" Window="SafeTopLevelWindows" Clipboard="OwnClipboard" />
          <IPermission 
class="System.Drawing.Printing.PrintingPermission, System.Drawing, 
Version=1.2.3400.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" 
version="1" Level="SafePrinting" />
          <IPermission class="MSAvalon.Windows.AVTempUIPermission, 
PresentationFramework, Version=6.0.4030.0, Culture=neutral, 
PublicKeyToken=a29c01bbd4e39ac5" version="1" 
NewWindow="LaunchNewWindows" FullScreen="SafeFullScreen" />
        </PermissionSet>
        <DefaultAssemblyRequest PermissionSetReference="SeeDefinition" 
/>
      </ApplicationRequestMinimum>
    </Security>
  </TrustInfo>
  <dependency asmv2:name="MyLonghornApp">
    <dependentAssembly>
      <assemblyIdentity name="MyLonghornApp" version="0.0.0.0" 
processorArchitecture="x86" />
    </dependentAssembly>
    <asmv2:installFrom codebase="MyLonghornApp.exe" 
hash="28c18a303c7fb7e9fe43a32b456f0932f52125a9" hashalg="SHA1" 
size="110592" />
  </dependency>
</assembly>

Управляемое приложение, совместимое с LUA, всегда будет содержать такой раздел, и диспетчер доверия в Longhorn будет использовать эти сведения, чтобы определить, следует ли разрешить установку приложения на компьютере. Если приложение закодировано тщательно, оно может работать с такими низкими привилегиями, что диспетчер доверия может назначить ему оценку "без риска", и приложение можно установить немедленно и запустить без вмешательства пользователя. Однако если приложение оценивает более опасные риски на основе запрашиваемых разрешений, пользователю будет предложено диалоговое окно с описанием потенциальных опасностей, которые представляет приложение. Затем пользователь может выбрать, следует ли разрешить установку и запуск приложения.

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

В исследовании, упомянутом на PDC 2003, корпорация Майкрософт обнаружила, что 40 процентов пользователей всегда нажимают кнопку "Нет" при появлении диалоговых окон безопасности, таких как предупреждения о скачивании элементов ActiveX. Ясно, что если вы хотите распространить программное обеспечение среди пользователей через Интернет, вы будете надеяться на оценку риска "без риска" от диспетчера доверия в Longhorn, поэтому пользователю не будет предложено перед установкой и запуском приложения. Поэтому вам может быть интересно, существует ли задокументированный набор разрешений, которые всегда будут оценены как "без риска". Оказывается, что существует такое определение, которое называется набором разрешений SEE.

Набор разрешений "Без риска"

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

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

Как это выглядит? Еще один взгляд на манифест в листинге 1. Обратите внимание на идентификатор, заданный для набора разрешений , определенного в разделе TrustInfo, SeeDefinition.

Вот как выглядит набор разрешений без риска для сборки предварительной версии PDC 2003: Неограниченный fileDialogPermission позволяет считывать или записывать файлы по выбору пользователя с помощью стандартных классов OpenFileDialog и SaveFileDialog , но вы не можете узнать что-либо о структуре файловой системы пользователя, включая имя файла, выбранного пользователем. IsolatedStoragePermission позволяет сборке считывать и записывать до 5 мб пользовательского состояния на жестком диске пользователя без запроса диалогового окна файла. SecurityPermission позволяет выполнять код в первую очередь. UiPermission позволяет рисовать на экране, но только в собственных окнах, и предоставляет ограниченный доступ к буферу обмена (вы не можете читать его содержимое программным способом, но пользователь может вставить его из буфера обмена в элементы управления). PrintingPermission позволяет выполнять печать, но только в том случае, если это можно сделать в диалоговом окне печати. Ваш код не может автоматически запускать задания печати, если пользователь не знает, что вы это делаете. Разрешение Avalon позволяет коду создавать полноэкранные окна при условии, что они имеют границу, контролируемую операционной системой (например, вы не можете подделать экран входа).

Имейте в виду, что это определение почти наверняка изменится со временем; он может даже измениться до longhorn бета-кораблей. Так что возьмите мое описание здесь с зерном соли. Мы надеемся, что эта статья поможет вам приступить к просмотру некоторых функций с минимальными привилегиями в платформа .NET Framework таких как изолированное хранилище и общие диалоги, так как окончательное определение набора разрешений без риска, скорее всего, потребует использования этих функций, чтобы избежать диалога доверия.

Определение набора разрешений без риска не является тривиальной задачей. Команда Longhorn знает, что если его определение слишком ограничительно, недостаточно приложений сможет его использовать. Но если это слишком разрешительно, вредоносные программы, безусловно, будет злоупотреблять им. Один надеется, что команда сможет найти сладкое пятно. На рисунке 1 показана схема, на которой показан диапазон привилегий для приложений Longhorn— от приложения для администрирования до приложений, предназначенных для работы с набором разрешений SEE.

Рис. 1. Типы приложений

Инструменты

Создание приложений с минимальными привилегиями никогда не было тривиальным. Вам нужны рекомендации и инструменты, которые помогут вам. Мы видели некоторые примеры этих средств в PDC 2003, первый из которых — Visual Studio® 2005 (кодовая версия Whidbey в период времени PDC 2003).

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

После начала отладки с ограниченными разрешениями вы наверняка столкнуться с непредвиденными исключениями SecurityException. На рисунке 2 показан классический пример, в котором разработчик использует диалоговое окно файла для запроса имени файла, а затем пытается прочитать предоставленное имя файла. Если вам предоставлен параметр FileDialogPermission (как и в наборе разрешений SEE), это позволяет запрашивать у пользователя файл, но вы, в частности, не будете видеть имя файла, выбранного пользователем. Вместо этого необходимо вызвать метод (OpenFile), чтобы открыть поток, который затем можно использовать для чтения из файла. Visual Studio 2005 предоставляет рекомендации, которые помогут разработчику найти правильный способ использования класса OpenFileDialog , чтобы избежать исключения безопасности.

Рис. 2. Улучшенная поддержка инструментов

Еще один полезный инструмент, который был объявлен на PDC 2003 называется PermCalc. Это программа командной строки, которая оценивает сборку и определяет с помощью эвристики разрешения, необходимые для запуска. Эта функция также планируется включить в Visual Studio 2005. Это отличный способ ориентироваться на среды с минимальными привилегиями. Аналогичный инструмент, который существует сегодня, называется "Проверка приложений Windows", который входит в набор средств совместимости приложений Windows. Это средство помогает обнаружить, когда приложение нарушает такие правила, как запись в защищенные части файловой системы или реестра.

Сводка

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

Дополнительные сведения см. в разделе

Прочтите книгу Брента Настоятеля ,Введение в "Longhorn" для разработчиков.

 

Об авторе

Кит Браун является независимым консультантом, специализирующимся на безопасности приложений. Он написал книгу Программирование Безопасность Windows (Addison-Wesley, 2000) и пишет новую книгу безопасности для программистов .NET. Читайте новую книгу в Интернете по адресу http://www.develop.com/kbrown.