CLR的SQL Server 2017年

MSDN上嚴格的安全性上this article說：CLR的SQL Server 2017年

CLR在.NET Framework，這是毫無不再支持作爲一個安全邊界使用代碼訪問安全（CAS）。使用 PERMISSION_SET = SAFE創建的CLR程序集可能能夠訪問外部系統資源，調用非託管代碼並獲取系統管理員權限。從開始，爲了增強CLR程序集的安全性，引入了一個名爲clr strict security的sp_configure選項。 clr strict 默認情況下啓用安全性，並將SAFE和EXTERNAL_ACCESS 程序集視爲標記爲UNSAFE。爲了向後兼容，可以禁用clr嚴格安全選項，但建議不要使用。 Microsoft建議所有程序集均使用證書或非對稱密鑰進行簽名，並在master數據庫中使用相應的登錄名，授予了UNSAFE ASSEMBLY權限。

使用PERMISSION_SET = SAFE創建的CLR程序集如何能夠訪問外部系統資源，調用非託管代碼並獲取系統管理員權限？

爲什麼不再支持CAS作爲安全邊界？

據我所知，CLR程序集不再安全，這是非常不幸的。

來源

2017-05-20 Jesús López

如何用PERMISSION_SET = SAFE創建的CLR程序集可以訪問外部系統資源，調用非託管代碼並獲取系統管理員權限？

這是由於在.NET Framework中進行的安全更改（從4.5版開始）（我相信）。

MSDN文檔Code Access Security Basics狀態：

.NET Framework提供了信任的不同層次的不同代碼，稱爲代碼訪問安全性（CAS）相同的應用程序中運行的實施機制。不應將.NET Framework中的代碼訪問安全性用作基於代碼起源或其他身份方面強制執行安全邊界的機制。我們正在更新我們的指導意見，以反映代碼訪問安全和安全透明代碼將不被支持作爲具有部分可信代碼的安全邊界，尤其是未知來源的代碼。我們建議不要加載和執行未知來源的代碼，而不採取其他安全措施。

然後指向頁面Security Changes in the .NET Framework其中規定：

在.NET Framework 4.5的安全性最重要的變化是強命名。

，然後指向它規定爲Enhanced Strong Naming的文檔：

強名稱密鑰由一個簽名密鑰和身份密鑰。程序集使用簽名密鑰進行簽名，並通過身份密鑰進行標識。在.NET Framework 4.5之前，這兩個密鑰是相同的。從.NET Framework 4.5開始，身份密鑰與早期的.NET Framework版本保持一致，但簽名密鑰使用更強大的哈希算法進行了增強。另外，簽名密鑰用身份密鑰簽名以創建一個反簽名。

而且，Secure Coding Guidelines狀態的文檔：

代碼訪問安全和安全透明的代碼將不被支持與部分受信任的代碼中的安全邊界。我們建議不要裝載和執行未知來源的代碼，而不採取其他安全措施......

因此，.NET的安全模型在幾年前就已改變，但SQL Server（直到SQL Server 2017）已被允許繼續使用舊的安全模型。看來，從SQL Server 2017開始，決定不再支持舊的安全模型。

我懷疑，讓舊的安全模式是：

防止SQL服務器（至少CLR相關的功能/組件）被基於較新版本的.NET Framework，並
負責突然去除SQLCLR的從Azure中的SQL數據庫支持的功能（支持已在2014年年底加入推出V12，但後來完全去除，2016年4月15日的）。

所以，是的，這有點兒吸。這意味着什麼（至少暫時）是一個需要第一創建證書或非對稱密鑰（已用於簽名被加載任何組件）到[master]來，然後創建一個登錄，然後授予UNSAFE ASSEMBLY到該登錄。這是相同的事件序列一個裝載EXTERNAL_ACCESS和UNSAFE組件時，但現在，不幸的是，需求甚至SAFE大會做需要做的。

目前沒有機制能夠移植到處理此（即，不依賴於外部文件），並且不能由Visual Studio/SSDT無需手動干預來處理。事實上，情況已經如此了，但至少可以創建一個設置來以完全便攜的方式處理這個問題（即完全包含在.sql腳本中）：請參閱Stairway to SQLCLR Level 7: Development and Security以獲取詳細信息（這是我寫的一篇文章）。

它可以創建從十六進制字節的證書（即FROM BINARY = 0x...），但/ SSDT因爲使用證書需要使用signtool不與Visual Studio（其依賴於MSBuild的）工作，並且使用的MSBuild sn。

爲了使它成爲可行的，以便Visual Studio/MSBuild/SSDT發佈過程起作用（這反過來意味着任何人都可以創建一個完全自包含的.sql腳本，能夠創建非對稱密鑰不依賴於外部文件），CREATE ASYMMETRIC KEY命令需要增強以允許從二進制字符串創建。我已經對微軟連接這個建議– Allow Asymmetric Key to be created from binary hex bytes string just like CREATE CERTIFICATE –所以請支持它:-)。或者（現在，直到MS希望創建一個更好的方法，比如我的非對稱密鑰建議），您可以嘗試我在以下博客文章中描述的兩種技術中的任何一種（均可與SSDT一起使用）：

作爲最後的手段，可以考慮以下方法：

TEMPORARILY設置[master]數據庫到TRUSTWORTHY ON
創建大會[master]
創建一個從大會
降的非對稱密鑰大會
設置[master]數據庫到TRUSTWORTHY OFF
從不對稱密鑰創建登錄
格蘭特UNSAFE ASSEMBLY到登錄

請注意，我沒有不包括新的「可信大會」功能作爲一個不錯的選擇。沒有提及的原因是它有更多的缺點而不是好處，更不用說它首先是完全沒有必要的，因爲現有的功能已經處理了「可信大會」旨在解決的情況。有關詳細信息以及處理現有未簽名程序集的正確方法演示，請參閱：SQLCLR vs. SQL Server 2017, Part 4: 「Trusted Assemblies」 – The Disappointment。

來源

2017-05-20 13:46:31

我前幾天看到這個消息，看起來並不像聽起來那麼糟糕（除了你不能再創建一個SAFE程序集，但需要簽署它等等，或者使用TRUSTWORTHY ）。

在我的測試：

我創建了一個「安全」的方法以及「不安全」的組件（它使用的任務）。
我創建的程序集是安全的（因建後簽署等）
我創造了我的身邊兩種方法T-SQL包裝功能。
執行「安全」功能時，所有工作。
執行「不安全」時，我收到一個HostProtectionException。

對我來說，這表示仍然有一些控制什麼正在執行。我遵循的增長：

與PERMISSION_SET =不安全

重新創建功能

重新創建裝配
現在，當我執行不安全的功能都如預期的工作。

所以我不太確定「clr嚴格安全性」文檔中的聲明是否100％正確。

我寫的我的經驗博客，帖子，你可以在這裏找到它，如果你想測試一下你自己：http://www.nielsberglund.com/2017/07/02/sql-server-2017-sqlclr-and-permissions/

尼爾斯

來源

2017-07-02 07:17:29

非常漂亮的博客，帖子，非常感謝你。所以你認爲這句話「可能能夠訪問外部系統資源，調用非託管代碼並獲得系統管理員權限」是不正確的。也許你需要做一些奇特的事來繞過安全檢查 –

嗨耶！是的 - 我認爲這是不正確的，至少不是基於我的測試。 –

CLR的SQL Server 2017年

回答

相關問題