Реализация IPermission для обеспечения безопасности доступа к пользовательскому коду

Question

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

Поэтому я создал CustomPermissionAttribute, который должен использоваться, как показано:

[CustomPermissionAttribute(SecurityAction.Demand, Permission="PermMethodABC")]
public void MethodABC() 
{ 
}

CreatePermission() Метод Attribute создает и возвращает новый экземпляр CustomPermission.

Метод Demand класса CustomPermission должен проверить безопасность в отношении моей пользовательской реализации IPrincipial в Thread.Current.CurrentPrincipial:

public sealed class CustomPermission : IPermission
{
    private string _RequiredPermission;
    ...
    public void Demand()
    {
        ICustomPrincipial _pr = Thread.Current.CurrentPrincipial as ICustomPrincipial;
        if (_pr == null) throw...
        if (!_pr.HasPermission(_RequiredPermission)) throw...
    }
}

public interface ICustomPrincipial : IPrincipial
{
    bool HasPermission(string RequiredPermission);
}

Все вышеперечисленное находится в подписанной "Ассамблее А".

Сборка B без знака содержит следующую реализацию CustomPrincipial, которая реализует ICustomPrincipial сборки A:

public sealed class CustomPrincipial : ICustomPrincipial
{
    User _User;
    ...
    public bool HasPermission(string RequiredPermission)
    {
        if (_User has permission defined with "PermMethodABC") ...
        return true/false;
    }
    ...
}

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

При запуске приложения новый экземпляр CustomPrincipial назначается для Thread.Current.CurrentPrincipial.

Два вопроса:

• Могут ли быть проблемы безопасности, вызванные общедоступным интерфейсом ICustomPermission в сборке A?

• Обязательно ли полностью реализовывать всех членов IPermission? Особенно методы ToXML и FromXML... Метод CreatePermission() все равно вызывается каждый раз, когда я обращаюсь к MethodABC() во время выполнения.

РЕДАКТИРОВАТЬ: объявление 1: Я думаю о следующей ситуации: "Сборка C" содержит MethodXY, который защищен атрибутом CustomPermissionAttribute. Чтобы получить доступ к этому защищенному методу, злоумышленник может создать новое приложение со ссылками на сборку A и сборку C и создать собственную реализацию общедоступного интерфейса ICustomPrincipial сборки A (-> HasPermission(), возвращающее true все время). Он мог назначить экземпляр своей реализации своему собственному Thread.Current.CurrentPrincipial. Если метод Demand() сборки A сверяется с Thread.Current.CurrentPrincipial, злоумышленник может получить доступ к MethodXY. Это может быть возможной ситуацией..!?

Answer 1

Могут ли быть проблемы безопасности, вызванные общедоступным интерфейсом ICustomPermission в сборке A?

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

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

Обязательно ли полностью реализовывать всех членов IPermission? Особенно методы ToXML и FromXML... Метод CreatePermission() все равно вызывается каждый раз, когда я обращаюсь к MethodABC() во время выполнения.

На странице msdn есть пример полной реализации, он не выглядит слишком неприятным и гарантирует, что у вас не возникнет проблем в дальнейшем из-за NotImplementedException,

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

РЕДАКТИРОВАТЬ: Это больше комментарий, но немного долго.

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

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

Если это не объясняет достаточно хорошо, дайте мне знать, и я могу добавить больше деталей.