Как отметить сборку .net как безопасную?

Как отметить как сборку как "безопасную"?

В качестве альтернативы, как мне Visual Studio скажет мне, когда что-то в моей сборке не "безопасно"?

Иногда вы не можете использовать сборку, если она не "безопасна" (например, из SQL Server).

Мне хотелось бы, чтобы моя сборка была помечена как безопасная. Если моя сборка не может быть помечена как безопасная, потому что она небезопасна, я хотел бы знать, как я могу знать, что моя сборка небезопасна.

В Visual Studio есть несколько концепций, которые, по-видимому, связаны с безопасностью, которая может или не может иметь ничего общего с безопасностью сборки:

  • Разрешить небезопасный код:

    enter image description here

    • Что разрешено, если я могу проверить вариант использования небезопасного кода?
    • Что не разрешено, если я снижу флажок разрешить вариант небезопасного кода?

    • Какое отношение, если таковое имеет место, относится к "небезопасному коду", когда сборка "безопасна" ?

      (я спрашиваю, потому что моя сборка не позволяет "разрешить небезопасный код", но разрешает вызовы P/Invoke, которые, по моему мнению, были определением "небезопасно" )

  • ClsCompliant:

    [assembly: CLSCompliant(true)]
namespace MyApplication
    • Какое отношение, если таковое имеет отношение, соответствует коду "cls-совместимый", когда сборка "безопасна" ?

  • небезопасный блок кода:

    int error;
unsafe
{
    error = 0x80004005;
}

    Код внутри блока unsafe "небезопасен"

  • UnsafeNativeMathods

    Корпорация Майкрософт рекомендует создать класс под названием UnsafeNativeMethods, который содержит небезопасный управляемый код:

    [SuppressUnmanagedCodeSecurity]
internal static class UnsafeNativeMethods
{
   ...          
}

    Это контрастирует с SafeNativeMethods:

    [SuppressUnmanagedCodeSecurity]
internal static class SafeNativeMethods
{
   ...          
}

    который содержит безопасные собственные методы и NativeMethods:

    internal static class SafeNativeMethods
{
   ...          
}

    которые содержат встроенные методы.

Как отметить как сборку как "безопасную"?

Как SQL знает, что, поскольку сборка "небезопасна"?

Ответы

Ответ 1

  • Чтение из этого, "Безопасный" для SQL Server:

SAFE - это самый ограничительный набор разрешений.      Код, выполняемый сборкой с разрешениями SAFE, не может получить доступ      внешние системные ресурсы, такие как файлы, сеть, окружающая среда      переменные или реестр

поэтому его разрешение на выполнение кода установлено внутри домена кода SQL Server

  • Unsafe флаг VS не имеет ничего общего с безопасностью выполнения кода, но позволяет выполнять не управляемый код. Таким образом, это о не управляемой интеграции кода в управляемую базу кода

  • CLS Compilant атрибут как определенный здесь посвящен определению кода сборки, помеченной этим атрибутом, как код, следующий за CSL (Common Language Specification). Итак, это касается компиляции и архитектуры кода.

Как отметить как сборку как "безопасную"?

Он определен в первой ссылке в этом ответе и имеет отношение к интеграции SQL Server.

Как SQL знает, что, поскольку сборка "небезопасна"?

Учитывая приведенное описание: "Создает управляемый модуль приложения, который содержит метаданные классов и управляемый код как объект в экземпляре SQL Server", ретрансляторы SQL Server на metadata, которые в некоторых полях предоставляют информацию о том, действительно ли это "безопасно" или нет.

Ответ 2

Как отметить как сборку как "безопасную"?

Вы думаете об этом неправильно.

Кто-то, кто, по вашему мнению, может захотеть убить вас руками, вы бутылку и говорит "пить это". Вы говорите: "Безопасно ли пить?" Парень говорит: "Почитай бутылку". Вы делаете. На нем написано "БЕЗОПАСНО ПИТЬ".

Вы пьете?

Безопасна ли жидкость для питья или нет, не имеет ничего общего с тем, что говорит этикетка на бутылке! Вполне возможно поставить бензин в бутылку с надписью "SAFE TO DRINK".

Вы парень, который выдает бутылку с подозрительной жидкостью на SQL-сервер, а SQL Server говорит: "Я не доверяю никакому ярлыку, который вы собираетесь разместить на этой сборке". Скорее, он собирается сделать сборку "безопасной", ограничив то, что может сделать сборка. Он блокирует разрешения на эту вещь, так что любая попытка вашей сборки использовать сервер SQL приведет к ее завершению с помощью исключения.

Как узнать, когда что-то в моей сборке не "безопасно"?

Попробуйте запустить его с низким доверием. Разрушился ли он и умер с исключением безопасности? Если ответ "да", то он небезопасен в соответствии с этим уровнем доверия. Различные уровни доверия предоставляют разные уровни разрешений. Код, который вы устанавливаете на свой собственный компьютер, как правило, полностью доверен, код, который вы запускаете из вашей корпоративной сети, менее доверен, код, который вы запускаете из Интернета, вряд ли доверен вообще. Код, который вы запускаете на SQL-сервере, получает наименьший уровень доверия для всех; он думает, что почти все небезопасно.

Что разрешено, если я могу проверить вариант разрешить небезопасный код?

Затем вы можете написать код, который непосредственно манипулирует необработанными указателями на память в порядке его выбора. Это требует полного доверия; на сборку не должно быть никаких ограничений, если вы хотите использовать небезопасный код. Небезопасный код может изменить каждый бит памяти пользовательского режима в процессе.

Какое отношение, если таковое имеет отношение, имеет код "cls compliant", связанный с безопасностью сборки?

Ничего, кроме того, что CLS-совместимый код не позволяет API-интерфейсам, которые используют типы raw-указателей.

CLS - это подмножество общего языка - набор функций, которые должны присутствовать на всех совместимых языках .NET. Таким образом, вам не нужно спрашивать себя: "Эй, если я напишу этот метод, который принимает int и возвращает строку в С#, могу ли я назвать ее из F #?" Если вы ограничитесь соблюдением правил CLS, вы знаете, что любой язык CLS может использовать вашу библиотеку, и вы можете использовать библиотеки, совместимые с CLS, независимо от того, на каком языке они были написаны. Он не имеет ничего общего с безопасностью.

Код внутри небезопасного блока "небезопасно"

Код внутри небезопасного блока может произвольно испортить память в течение всего процесса, если он написан плохо. Мы заставляем вас маркировать код как "небезопасный", чтобы вы знали, где сосредоточить усилия на анализе кода. В небезопасном блоке вы, а не язык С#, несете ответственность за обеспечение безопасности типов и памяти.

Вопрос, о котором вы не спрашивали:

Что означает маркировка сборки как "безопасная для частично доверенного абонента"?

Это ситуация, когда вы отмечаете сборку как "безопасную". Пометив сборку с помощью атрибута AllowPartiallyTrustedCallerAttribute (APTCA), вы, автор сборки, утверждаете, что если код в сборке вызывается с помощью низкоприоритетного враждебного кода, который пытается атаковать пользователя, то в вашей сборке ничего нет который может использоваться против пользователя с низким доверием. Короче говоря, вы говорите: "Даже если вы полностью доверяете пользователю, мой код не является оружием, которое может использовать код злоумышленника против пользователя".

Мы изобрели APTCA, потому что в тот же день Питер Торр и я обнаружили, что существует способ для враждебных абонентов, которым было мало доверия, чтобы обмануть код JScript.NET - который был высоким доверием по умолчанию - таким образом что низкий код доверия может привести к тому, что код JScript.NET атакует пользователя от его имени. (Обычно это называется "приманкой атаки", потому что код с низким доверием "заманивает" код высокого доверия для выполнения его грязной работы для него.)

Как одна небольшая часть большого усилия, чтобы убедиться, что такого рода ошибка не повторилась, команда CLR представила APTCA. Поместив APTCA на сборку, вы сообщаете своим пользователям, что вы утверждаете, что их доверие к вашей работе не злоупотребляет враждебным сторонним кодом. Не ставьте APTCA на сборку, если только (1) вы не собираетесь, чтобы сборка вызывалась по коду, который, по мнению пользователя, может быть враждебным, и (2) вы действительно провели тщательный обзор безопасности.

Новая система безопасности на основе прозрачности, к счастью, почти не требует использования APTCA.

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

Ответ 3

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

http://msdn.microsoft.com/en-us/library/chfa2zb8.aspx

Ответ 4

В зависимости от того, что вы имеете в виду, но если вы импортируете сборку (например, DLL), в свойствах этого файла .dll есть опция "разблокировать". Это позволит вам использовать dll в качестве ссылки.