.NET RegistrySecurity API обработка неканонических ACL: подход к обработке - PullRequest
Новая
       12

.NET RegistrySecurity API обработка неканонических ACL: подход к обработке

2 голосов
/ 10 февраля 2010

Я пытаюсь добавить правило доступа к RegistryKey примерно так: 

using ( RegistryKey registry = OpenOrCreateMyKey() )
{
    RegistrySecurity security = registry.GetAccessControl();
    security.AddAccessRule( new RegistryAccessRule(
        new SecurityIdentifier( WellKnownSidType.BuiltinUsersSid, null ),
        RegistryRights.WriteKey,
        InheritanceFlags.ContainerInherit | InheritanceFlags.ObjectInherit,
        PropagationFlags.None,
        AccessControlType.Allow ) );
    registry.SetAccessControl( security );
}

Однако, если реестр искажен, AddAccessRule выдает исключение (Reflector показывает, что вызов GetAccessControl определяет, что они не являются каноническими заранее, и вы отключаете систему безопасности, когда вы пытаетесь выполнить запись, когда RegistrySecurity экземпляр находится в этом состоянии): 

System.InvalidOperationException: This access control list is not in canonical form and therefore cannot be modified.

Запуск regedt32 (и, вероятно, regedit) затем показывает всплывающее окно, говорящее the permissions on <key> are incorrectly ordered, which may cause some entries to be ineffective <paraphrasing>Do you want to unmangle them now? Y/N</paraprasing>

Самая авторитетная статья, которую я видел по этому вопросу, - http://www.codeproject.com/KB/system/accessctrl3.aspx,, в которой говорится:

Однако флаги управления реализованы как свойства (поговорим о несоответствии!). Вы можете получить настройки автоматического наследования из AreAccessRulesProtected / AreAuditRulesProtected (напомним, если ACL защищен, он не наследуется автоматически). Если вы прочтете часть 2, вы узнаете, что некоторые из API-интерфейсов Windows не поддерживают наследование, поэтому могут повредить параметры наследования вашего компьютера. Хорошая новость заключается в том, что .NET полностью поддерживает механизм наследования и правильно сохраняет параметры наследования. Если вы открыли дескриптор безопасности, который каким-то образом получил неупорядоченный ACL (возможно, из какого-то мошеннического приложения Win32), InvalidOperationException будет выдано, если вы попытаетесь отредактировать его.

Как правило, такие неканонические ACL-списки являются результатом использования [с момента выхода на пенсию] инструмента NewSID , и люди пишут статьи в КБ, чтобы сказать: "Ну, тогда прекратите делать это" .

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

Я дам два ответа, и люди могут голосовать и выбирать дыры, голосовать, комментировать и придираться.

Ответы [ 2 ]

2 голосов
/ 10 февраля 2010

Подход 1 - игнорировать унаследованные разрешения и вслепую писать то, что вы хотели: - 

using ( RegistryKey registry = OpenOrCreateMyKey() )
{
    RegistrySecurity security = new RegistrySecurity();
    security.AddAccessRule( new RegistryAccessRule( ... ));
    registry.SetAccessControl( security );
}

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

1 голос
/ 10 февраля 2010

Подход 2 - попробовать первый путь и отступить на грязный путь только при необходимости: - 

using ( RegistryKey registry = OpenOrCreateMyKey() )
{
    RegistrySecurity security = new RegistrySecurity();
    if ( !security.AreAccessRulesCanonical )
    {
        Log.WriteWarning( "Registry permissions (likely ones inherited from parent) are inconsistent (RegistrySecurity.AreAccessRulesCanonical is false), so using alternate permissioning algorithm, Has NewSID or another tool mangled permissions? regedt32 can be used to analyze the issue." );
         // Ignore parent ACLs and just blindly stuff in this ACL (which will continue to be inherited)
         security = new RegistrySecurity();
     }

    security.AddAccessRule( new RegistryAccessRule( ... ));
    registry.SetAccessControl( security );
}

В дополнение к недостаткам подхода 1 , это имеет непредсказуемое поведение, но по крайней мере в некоторой степени совместимо с ошибками с оригинальным подходом.

...