Сообщений 5    Оценка 395        Оценить

Второй .NET – второй эшелон безопасности

Часть 1 – Контроль доступа

Автор: Сергей Бакланов
Источник: RSDN Magazine #1-2005

Опубликовано: 22.05.2005
Исправлено: 10.12.2016
Версия текста: 1.0

Идентификаторы безопасности Просмотр SID пользователя с помощью утилиты GetSID Получение SID средствами .NET Framework 2.0 Управление доступом Программирование ACL средствами .NET Framework 2 Защита файлов Защита реестра Язык SDDL Флаги DACL и SACL Формат ACE Стандартные SID Примеры SDDL-выражений Использование SDDL в .NET Framework 2 Заключение Ссылки

Архитектуре безопасности в NET Framework 1.x не хватало объектной модели программирования контроля доступа к файлам, реестру, системным службам. Проще говоря, до 2-й версии .NET не поддерживал списки контроля доступа (ACL – Access Control List).

Раньше для реализации поддержки ACL надо было использовать Authorization Manager API. В .NET 2.0 это можно сделать с помощью пространства имён System.Security.AccessControl. Эта статья посвящена описанию использования данного пространства имён для реализации контроля доступа средствами .NET Framework 2.0 BETA.

Чтобы ввести читателя в курс дела, начнём с теоретического введения и опишем основные понятия, на которых построена политика управления доступом.

Идентификаторы безопасности

Для идентификации пользователей Windows использует не их имена, которые могут оказаться и не уникальными, а идентификаторы безопасности (Security Identifier – SID). Идентификатор безопасности – это уникальное значение переменной длины, которое присваивается пользователям, доменам и членам доменов. Каждый идентификатор безопасности состоит из версии SID, 48-битного кода агента идентификатора и переменного числа 32-битных субагентов, или, как их ещё называют, относительных идентификаторов (Relative Identifier – RID). Код агента идентификатора выдаётся операционной системой: для NT-систем его значение – 5. Субагенты определяют информацию о домене, а последний RID – код пользователя. Таким образом, RID – это средство создания уникального SID на основе базового SID. Поскольку длина SID достаточно велика, Windows старается генерировать истинно случайное значение.

В текстовом представлении формат SID выглядит следующим образом:

S-R-I-S-S…

В текстовой форме все SID начинаются с префикса “S”, далее следует номер версии (R), код агента идентификатора (I) и группа RID (S).

Просмотр SID пользователя с помощью утилиты GetSID

Чтобы узнать SID пользователя, можно воспользоваться утилитой GetSID, входящей в состав набора ресурсов Windows 2000. Её можно загрузить по адресу http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/getsid-o.asp. Эта утилита была, в первую очередь, создана для сравнения SID разных пользователей, но может быть с тем же успехом использована для получения SID конкретного пользователя. Ниже приведён синтаксис её использования:

C:\>getsid
Usage: getsid \\server1 account \\server2 account

Как видно, для её работы нужно указать 2 домена и соответствующие учётные записи в этих доменах. Рассмотрим пример:

C:\>getsid \\bigdragon B@K$ \\bigdragon AlBa
The SID for account BIGDRAGON\B@K$ does not match account BIGDRAGON\AlBa
The SID for account BIGDRAGON\B@K$ is S-1-5-21-220523388-854245398-1343024091-1003
The SID for account BIGDRAGON\AlBa is S-1-5-21-220523388-854245398-1343024091-1004

Таким образом, SID пользователя B@k$ на машине автора представлен строкой S-1-5-21-220523388-854245398-1343024091-1003, а SID AlBa – S-1-5-21-220523388-854245398-1343024091-1004. Оба идентификатора начинаются с префикса “S”, затем следует версия SID – 1, код агента идентификатора – 5 (этот код характерен для всех NT-систем), далее идут коды 4-х субагентов, а в конце – RID, которые и отличаются у пользователей B@k$ и AlBa (в коде они выделены).

Все RID пользователей начинаются с 1000, увеличиваясь на 1 для каждой новой учётной записи. Таким образом, если запросить SID пользователя HelpAssistant, то его RID будет 1000:

C:\>getsid \\bigdragon HelpAssistant \\bigdragon HelpAssistant
The SID for account BIGDRAGON\HelpAssistant matches account BIGDRAGON\HelpAssist
ant
The SID for account BIGDRAGON\HelpAssistant is S-1-5-21-220523388-854245398-1343024091-1000
The SID for account BIGDRAGON\HelpAssistant is S-1-5-21-220523388-854245398-1343024091-1000

Система также поддерживает стандартные RID для некоторых учётных записей, например, RID для администратора – 500, а для гостя – 501:

C:\>getsid \\bigdragon Administrator \\bigdragon Guest
The SID for account BIGDRAGON\Administrator does not match account BIGDRAGON\Gue
st
The SID for account BIGDRAGON\Administrator is S-1-5-21-220523388-854245398-1343024091-500
The SID for account BIGDRAGON\Guest is S-1-5-21-220523388-854245398-1343024091-501

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

Получение SID средствами .NET Framework 2.0

Для работы с SID .NET Framework 2.0 предоставляет класс SecurityIdentifier пространства имён System.Security.Principal. Конструкторы этого класса позволяют задать SID в виде строки, массива байтов или комбинации перечисления WellKnownSidType и SID домена. С помощью этого класса можно узнать SID домена, которому принадлежит указанный идентификатор безопасности; является ли SID универсальным; является ли он идентификатором учётной записи и т.п.

Чтобы узнать SID учётной записи, от имени которой запущено приложение, нужно дополнительно воспользоваться классом WindowsIdentity того же пространства имён, как показано в листинге 1:

Листинг 1. GetSID – получение SID пользователя, от имени которого запущено приложение.

        using System;
using System.Security.Principal;

namespace GetSID
{
  class Program
  {
    staticvoid Main(string[] args)
    {
      WindowsIdentity wid = WindowsIdentity.GetCurrent();
      Console.WriteLine(wid.Name + " SID is {0}", wid.User.Value);
      Console.Read();
    }
  }
}

Статический метод GetCurrent класса WindowsIdentity возвращает описатель идентификатора аутентифицированного пользователя, от имени которого запущено приложение. Свойство User возвращает ссылку на класс SecurityIdentifier, идентифицирующий пользователя.

Запуск приложения от имени пользователя B@K$ вернёт следующий результат:

BIGDRAGON\B@k$ SID is S-1-5-21-220523388-854245398-1343024091-1003

Если запустить его от имени администратора, то будет выведено соответствующее сообщение:

BIGDRAGON\Administrator SID is S-1-5-21-220523388-854245398-1343024091-500

Управление доступом

Управление политикой доступа к ресурсам осуществляется с помощью списков контроля доступа (ACL – Access Control List). Списки контроля доступа делятся на 2 группы:

• Избирательные списки контроля доступа (DACL – Discretionary Access Control List) определяют права доступа к ресурсу.
• Системные списки контроля доступа (SACL – System Access Control List) отвечают за аудит событий.

ACL управляют доступом к самым разным объектам: файлам и папкам, локальным и удалённым принтерам, разделам реестра, именованным каналам, сетевым ресурсам, объектам синхронизации (семафоры, мьютексы, события, таймеры), объектам-заданиям, общей памяти, объектам каталога Active Directory, системным службам. Все эти возможности поддерживаются лишь в NT системах (Windows NT, 2000, XP, 2003).

Всякий ACL – это набор записей контроля доступа (ACE – Access Control Entry), каждая из которых состоит из SID (учётной записи, пользовательской группы или машины), маски доступа, определяющей права доступа, флагов, описывающих тип ACE (таблица 2), и набора флагов, указывающих на способность объектов или контейнеров-потомков наследовать политику безопасности данной ACL.

Все ресурсы, поддерживающие политику ACL, делятся на 2 группы: объекты и контейнеры. Объекты – это объекты службы каталогов (Directory Service), они идентифицируются по GUID, а контейнеры – это все остальные ресурсы, опознать которые можно по имени.

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

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

Программирование ACL средствами .NET Framework 2

Программирование ACL в .NET Framework 2 осуществляется с помощью классов пространства имён System.Security.AccessControl. Это пространство имён содержит целую иерархию наследуемых классов, таким образом, контроль доступа ко всем видам ресурсов осуществляется по одинаковой схеме с незначительными отличиями, характерными для соответствующих ресурсов.

Архитектура основных классов System.Security.AccessControl, использующихся для контроля доступа.

System.Object
  System.Security.AccessControl.ObjectSecurity
    System.Security.AccessControl.DirectoryObjectSecurity
      System.DirectoryServices.ActiveDirectorySecurity
    System.Security.AccessControl.CommonObjectSecurity
      Microsoft.Iis.Metabase.MetaKeySecurity
      System.Security.AccessControl.NativeObjectSecurity
        System.Security.AccessControl.EventWaitHandleSecurity
        System.Security.AccessControl.FileSystemSecurity
          System.Security.AccessControl.DirectorySecurity
          System.Security.AccessControl.FileSecurity
        System.Security.AccessControl.MutexSecurity
        System.Security.AccessControl.RegistrySecurity
        System.Security.AccessControl.SemaphoreSecurity

Защита файлов

Предположим, что нужно установить на файл C:\Temp\acl.txt DACL следующего формата:

• Гостям разрешить только чтение.
• Администраторам предоставить полный доступ.
• Учётной записи HelpAssistant дать права на чтение и модификацию данных.
• Пользователю AlBa запретить доступ.

Рисунок 1. Схема DACL.

Для демонстрации создадим новый проект консольного приложения и воспользуемся кодом из листинга 2:

Листинг 2. FileACL – установка DACL для файла.

        using System;
using System.Security.AccessControl;
using System.Security.Principal;using System.IO;

namespace FileACL
{
  class Program
  {
    staticvoid Main(string[] args)
    {
      conststring FILE_NAME = @"C:\Temp\acl.txt";
      FileInfo fi = new FileInfo(FILE_NAME);
      FileSecurity fs = new FileSecurity(FILE_NAME, AccessControlSections.All);

      fs.SetAccessRule(new FileSystemAccessRule("BIGDRAGON\\AlBa", 
                            FileSystemRights.FullControl, 
                            AccessControlType.Deny));
      fs.SetAccessRule(new FileSystemAccessRule("BUILTIN\\Administrators",
                            FileSystemRights.FullControl, 
                            AccessControlType.Allow));
      fs.SetAccessRule(new FileSystemAccessRule("BIGDRAGON\\HelpAssistant",
                            FileSystemRights.ReadData |
                            FileSystemRights.WriteData |
                            FileSystemRights.AppendData,
                            AccessControlType.Allow));
      fs.SetAccessRule(new FileSystemAccessRule("BUILTIN\\Guests",
                            FileSystemRights.ReadData,
                            AccessControlType.Allow));

      fi.SetAccessControl(fs);
    }
  }
}

Управление политикой доступа к файлу производится с помощью класса System.Security.AccessControl.FileSecurity. С его помощью можно добавлять, удалять, изменять права доступа и аудита к заданному файлу.

Во второй строке обработчика главной функции создаётся экземпляр класса System.IO.FileInfo, который ссылается на заданный файл и устанавливает политику безопасности. В следующей строке создаётся экземпляр класса FileSecurity: в качестве аргумента он принимает имя обрабатываемого файла и разделы, с которыми будет вестись работа (как правило, оставляют значение All). Далее добавляются правила доступа путём вызова метода SetAccessRule класса FileSecurity. Этот метод принимает один единственный аргумент типа FileSystemAccessRule, который и описывает правило доступа. После формирования объекта типа FileSecurity его передают в качестве аргумента методу SetAccessControl класса FileInfo.

Чтобы проверить результат, сперва выполните программу, а затем найдите обрабатываемый файл (в примере это был C:\Temp\acl.txt), откройте окно свойств и перейдите на закладку безопасности. Далее щёлкните кнопку Дополнительно и в появившемся окне (рисунок 2) увидите информацию по правам каждого пользователя.

Рисунок 2. Права доступа для HelpAssistant.

В листинге 1 DACL определён таким образом, что пользователь AlBa не имеет никаких прав на доступ к файлу. Чтобы проверить результат, выполните следующую команду:

C:\>runas /user:Alba "notepad C:\Temp\acl.txt"

В результате должно появиться сообщение об отказе в доступе.

Дополнительные возможности

Если права пользователя уже определены, но нужно добавить ещё одно, необходимо вызвать метод AddAccessRule. К примеру, добавим HelpAssistant’у возможность просматривать значения атрибутов файла:

fs.AddAccessRule(new FileSystemAccessRule("BIGDRAGON\\HelpAssistant",
  FileSystemRights.ReadAttributes, AccessControlType.Allow));

Для удаления какого-то одного разрешения (ACE) предназначен метод RemoveAccessRule:

fs.RemoveAccessRule(new FileSystemAccessRule("BIGDRAGON\\HelpAssistant",
  FileSystemRights.ReadAttributes, AccessControlType.Allow));

Если нужно удалить сразу все правила для какой-то конкретной учётной записи (т. е. полностью вычеркнуть учётную запись из ACL), то необходимо вызвать метод PurgeAccessRules. Прототип этого метода выглядит так:

          public
          void PurgeAccessRules(System.Security.Principal.IdentityReference identity);

Как видно, он принимает ссылку на объект IdentityReference. IdentityReference – это абстрактный класс, который наследуется классами NTAccount и SecurityIdentifier (все три класса находятся в пространстве имён System.Security.Principal). Соответственно с помощью класса NTAccount можно указать имя учётной записи, а через SecurityIdentifier – SID:

fs.PurgeAccessRules(new NTAccount("BIGDRAGON\\HelpAssistant"));

или

fs.PurgeAccessRules(
  new SecurityIdentifier("S-1-5-21-220523388-854245398-1343024091-1000"));

После выполнения этого кода все записи, описывающие правила для HelpAssistant’а будут удалены (см. рисунок 3).

Рисунок 3. HelpAssistant’а больше нет в списке.

С помощью методов SetOwner и SetGroup можно установить владельца и основную группу соответственно. Эти методы так же, как и PurgeAccessRule, принимают в качестве аргумента SID или имя учётной записи:

          public
          void SetOwner(System.Security.Principal.IdentityReference identity);
publicvoid SetGroup(System.Security.Principal.IdentityReference identity);

Аудит

Аудит настраивается аналогичным образом, с тем лишь отличием, что в именах соответствующих методов вместо Access пишется Audit. Например, конфигурирование SACL для того, чтобы при чтении данных HelpAssistant’ом в журнал добавлялась запись аудита, будет выглядеть следующим образом:

fs.AddAuditRule(new FileSystemAuditRule("BIGDRAGON\\HelpAssistant",
  FileSystemRights.ReadData, AuditFlags.Success));

Чтобы убедиться в том, что аудит чтения данных HelpAssistant’ом действительно установлен, нужно открыть окно свойств файла, перейти на закладку Безопасность, нажать кнопку Дополнительно и в появившемся окне выбрать закладку Аудит (рисунок 4).

Рисунок 4. – Окно параметров аудита.

Чтобы увидеть результат аудита, нужно открыть файл под учётной записью HelpAssistant. Это можно сделать следующей командой:

C:\>runas /user:HelpAssistant "notepad C:\temp\acl.txt"

После открытия файла его можно закрыть, а затем нужно открыть консоль просмотра событий и перейти в журнал Безопасность (рисунок 5)

Рисунок 5. Результат аудита.

Рисунок 6. Активация аудита успешного доступа к объектам.

Защита реестра

Защита реестра осуществляется так же, как и защита файлов, но с тем отличием, что используются объекты RegistrySecurity (описатель безопасности реестра) и RegistryKey (класс для работы с разделами реестра).

К примеру, нужно создать новый раздел реестра и назначить такие права доступа, чтобы HelpAssistant мог читать и изменять данные, AlBa не имел доступа, а администраторам был предоставлен полный доступ. Листинг 3 содержит код выполняющий эти действия.

Листинг 3. RegistryACL – создание DACL для раздела реестра.

        using System;
using Microsoft.Win32;    // Содержит классы для работы с реестромusing System.Security.AccessControl;

namespace RegistryACL
{
  class Program
  {
    staticvoid Main(string[] args)
    {
      RegistryKey reg = Registry.LocalMachine.CreateSubKey("Software");
      RegistrySecurity rs = new RegistrySecurity();

      rs.SetAccessRule(new RegistryAccessRule("BIGDRAGON\\AlBa",
                          RegistryRights.FullControl,
                          AccessControlType.Deny));
      rs.SetAccessRule(new RegistryAccessRule("BUILTIN\\Administrators",
                          RegistryRights.FullControl,
                          AccessControlType.Allow));
      rs.SetAccessRule(new RegistryAccessRule("BIGDRAGON\\HelpAssistant",
                          RegistryRights.ReadKey |
                          RegistryRights.WriteKey,
                          AccessControlType.Allow));
      // Отменяет наследование параметров от родителя, но передаёт свои значения потомкам
      rs.SetAccessRuleProtection(true, true); 

      reg = reg.CreateSubKey("ACLtest");
      reg.SetAccessControl(rs);

      reg.Close();
    }
  }
}

В листинге 3 сначала открывается раздел реестра HKLM\Software, затем создаётся новый экземпляр описателя безопасности раздела реестра. После этого следуют 3 конструкции, устанавливающие соответствующие права доступа для 3-х учётных записей. Следующая строка:

rs.SetAccessRuleProtection(true, true);

является необязательной, но удобна тем, что после её выполнения в DACL не попадут записи от родителя, т. е. от раздела HKLM\Software. Первый параметр метода SetAccessRuleProtection активирует/деактивирует наследование параметров от родителя, а второй – разрешает/запрещает передавать параметры потомкам.

В следующих 2-х строках:

reg = reg.CreateSubKey("ACLtest");
reg.SetAccessControl(rs);

открывается (или создаётся, если он ещё не существует) раздел реестра HKLM\Software\ACLtest и устанавливается DACL для него путём вызова метода SetAccessControl. Эти 2 строки можно заменить одной:

reg.CreateSubKey("ACLtest", rs);

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

Чтобы убедиться в успешности выполнения кода из листинга 3, просмотрите разрешения на раздел реестра HKLM\Software\ACLtest (рисунок 7) или выполните следующую команду:

runas /user:AlBa regedit

и перейдите к разделу HKLM\Software\ACLtest. Если всё было выполнено правильно, то система вас не пропустит.

Рисунок 7. Разрешения доступа к разделу реестра HKLM\Software\ACLtest.

Язык SDDL

Давным-давно, в далёкой-далёкой галактике под названием NT 4 разработчикам жилось тяжело, потому что процесс программирования ACL был весьма трудоёмкой задачей. Тогда повстанческие силы под предводительством атамана Билла Гейтса решили облегчить им эту задачу, разработав язык определения дескриптора безопасности SDDL – Security Descriptor Definition Language.

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

O:sid_владельца
G:sid_основной_группы
D:флаги_DACL(ACE 1)(ACE 2)…(ACE n)
S:флаги_SACL(ACE 1)(ACE 2)…(ACE n)

Эти четыре конструкции могут существовать вместе или по отдельности, и различаются по префиксам:

• O: – Owner (владелец).
• G: – Primary Group (основная группа).
• D: – DACL.
• S: – SACL.

Флаги DACL и SACL

DACL- и SACL-флаги используют одни и те же значения и применяются для управления наследованием параметров. Список допустимых значений приведен в таблице 4.

Формат ACE

ACE записи содержат всю информацию, описывающую права доступа и аудита для каждой учётной записи. В языке SDDL они имеют следующий формат:

(тип_ACE;флаги_ACE;права;GUID_объекта;GUID_наследуемого_объекта;SID)

Поддерживаемые типы ACE перечислены в таблице 5.

В поле GUID_объекта при необходимости (в случае работы с объектами Active Directory) подставляется GUID соответствующего объекта. Поле GUID_наследуемого_объекта содержит GUID типа объекта, которому должны отвечать все объекты-потомки.

Стандартные SID

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

Примеры SDDL-выражений

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

D:P(D;OICI;GA;;;S-1-5-21-220523388-854245398-1343024091-1004)(A;OICI;GA;;;BA)(A;OICI;GRGW;;;S-1-5-21-220523388-854245398-1343024091-1000)(A;OICI;GR;;;BG)

Рассмотрим эту запись:

• Здесь приведено описание только DACL (D:).
• Флаг P запрещает наследование параметров от родителя.
• 1-я ACE запрещает пользователю AlBa (в коде стоит его SID: S-1-5-21-220523388-854245398-1343024091-1004) доступ к файлу.
• 2-я ACE даёт встроенной группе администраторов все полномочия.
• 3-я ACE разрешает HelpAssistant’у чтение и модификацию данных (GRGW – GenericRead и GenericWrite).
• 4-я ACE ограничивает встроенную группу гостей возможностью только чтения данных.

Во всех ACE использовались флаги OICI, активирующие наследование потомками параметров объектов и контейнеров.

Если к этой конструкции нужно добавить аудит успешного чтения данных HelpAssistant’ом, то в конец строки можно подставить следующее выражение:

S:P(AU;SA;GR;;;S-1-5-21-220523388-854245398-1343024091-1000)

Ниже приведены отличия кода SACL от кода DACL:

• Вместо префикса D используется S
• Тип ACE определён не как разрешающий (A) или запрещающий (D), а как ACE аудита (AU)
• Флаг ACE устанавливает не параметры наследования (хотя их тоже можно было добавить), а флаг аудита успешного выполнения операции (SA)

Использование SDDL в .NET Framework 2

Для демонстрации работы SDDL создадим новый проект и воспользуемся кодом из листинга 4:

Листинг 4. SDDL – Настройка DACL и SACL файла с помощью SDDL выражения.

        using System;
using System.IO;
using System.Security.AccessControl;

namespace SDDL
{
  class Program
  {
    staticvoid Main(string[] args)
    {
      conststring FILE_NAME = @"C:\Temp\acl.txt";
      FileInfo fi = new FileInfo(FILE_NAME);
      FileSecurity fs = new FileSecurity(
        FILE_NAME, AccessControlSections.All);

      fs.SetSecurityDescriptorSddlForm("D:P" +
        "(D;OICI;GA;;;S-1-5-21-220523388-854245398-1343024091-1004)" 
        + "(A;OICI;GA;;;BA)" +
        + "(A;OICI;GRGW;;;S-1-5-21-220523388-854245398-1343024091-1000)"
        + "(A;OICI;GR;;;BG)"
        + "S:P"
        + "(AU;SA;GR;;;S-1-5-21-220523388-854245398-1343024091-1000)");
      fi.SetAccessControl(fs);
    }
  }
}

Если сравнить листинги 1 и 4, то очевидно, что последний значительно короче, но его использование требует знание языка SDDL.

Для получения из дескриптора безопасности строки SDDL нужно вызвать метод GetSecurityDescriptorSddlForm, который доступен для всех объектов, поддерживающих ACL. В листинге 5 показано, как получить SDDL-строку с параметрами ACL для файла C:\Temp\acl.txt.

Листинг 5. GetSDDL – Получение строки SDDL с параметрами ACL файла C:\Temp\acl.txt.

        using System;
using System.IO;
using System.Security.AccessControl;

namespace SDDL
{
  class Program
  {
    staticvoid Main(string[] args)
    {
      FileInfo fi = new FileInfo(@"C:\Temp\acl.txt");
      Console.WriteLine(fi.GetAccessControl().GetSecurityDescriptorSddlForm(
        AccessControlSections.All));
    }
  }
}

Если выполнить этот код сразу после кода из листинга 4, то будет очевидно, что система перестроила ACL под свой формат:

O:S-1-5-21-220523388-854245398-1343024091-1003G:S-1-5-21-220523388-854245398-1343024091-513D:PAI(D;;FA;;;S-1-5-21-220523388-854245398-1343024091-1004)(A;;FA;;;BA)(A;;FR;;;BG)(A;;0x12019f;;;S-1-5-21-220523388-854245398-1343024091-1000)

Как видно, в строке SDDL появилась информация о владельце, основной группе, изменилась форма записи ACE, исчезли списки SACL.

Заключение

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

Ссылки

1. Утилита GetSID: http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/getsid-o.asp
2. Документация по ACL: http://msdn.microsoft.com/library/en-us/secauthz/security/access_control.asp

Сообщений 5    Оценка 395        Оценить