Как работает модель прозрачности в .Net Framework

В модели прозрачности методы, критические с точки зрения безопасности, помечаются с помощью атрибута [SecurityCritical]:

[SecurityCritical]

public Key GetTVRoomKey() { ... }

Все “опасные” методы (содержащие код, который среда CLR считает нарушающим безопасность) должны быть помечены посредством атрибута [SecurityCritical] или [SecuritySafeCritical]. В число таких методов входят:

• непроверяемые (unsafe) методы;

• методы, которые обращаются к неуправляемому коду через P/Invoke или взаимодействие с СОМ;

• методы, которые утверждают разрешения или вызывают методы с требованиями связывания;

• методы, которые вызывают методы [SecurityCritical];

• методы, которые переопределяют виртуальные методы [SecurityCritical].

Атрибут [SecurityCritical] означает: “данный метод может разрешить вызывающей сборке с частичным доверием покинуть песочницу”.

Атрибут [SecuritySafeCritical] означает: “данный метод выполняет критические с точки зрения безопасности действия — но с соответствующими защитными мерами, поэтому он безопасен для вызывающих сборок с частичным доверием”.

Методы в сборках с частичным доверием никогда не могут вызывать подобные методы в сборках с полным доверием. Методы [SecurityCritical] могут быть вызваны только следующими методами:

• другими методами [SecurityCritical];

• методами, помеченными как [SecuritySafeCritical].

Прозрачный код

В рамках модели прозрачности все методы подпадают под одну из следующих категорий:

• критические с точки зрения безопасности;

• надежные с точки зрения безопасности;

• ни те, ни другие (в этом случае они называются прозрачными).

Прозрачные методы так называются потому, что их можно игнорировать при проведении аудита кода на предмет уязвимости к атакам повышением привилегий. Понадобится лишь сосредоточить внимание на методах [SecuritySafeCritical] (привратниках), которые обычно составляют только небольшую часть методов сборки. Если сборка состоит полностью из прозрачных методов, то вся сборка может быть помечена атрибутом [SecurityTransparent ]:

[assembly: SecurityTransparent]

После этого говорят, что сборка сама является прозрачной. Прозрачные сборки не требуют аудита на предмет уязвимости к атакам повышением привилегий и неявно позволяют обращаться вызывающим сборкам с частичным доверием — применять атрибут АРТСА не нужно.

Настройка прозрачности по умолчанию для сборки

Подводя итоги сказанному ранее, существуют два способа указания прозрачности на уровне сборки.

• Применение атрибута АРТСА. Все методы станут неявно прозрачными кроме тех, которые помечены иначе.

• Применение атрибута сборки [SecurityTransparent]. Все методы станут неявно прозрачными безо всяких исключений.

Третий способ — не делать ничего. Это по-прежнему предполагает применение правил прозрачности, но с каждым методом, неявно являющимся [SecurityCritical] (кроме любых переопределенных виртуальных методов [SecuritySafeCritical], которые останутся критическими с точки зрения безопасности). Эффект заключается в том, что ваша сборка может вызвать любой желаемый метод (предполагая наличие у нее полного доверия), но прозрачные методы из других сборок не могут обращаться к вашей сборке. Xrust: Как работает модель прозрачности в .Net Framework