Cách lắp ráp CLR được tạo với PERMISSION_SET = SAFE có thể truy cập tài nguyên hệ thống bên ngoài, gọi mã không được quản lý và nhận đặc quyền sysadmin?
Điều này là do các thay đổi bảo mật được thực hiện trong Khuôn khổ .NET, bắt đầu từ phiên bản 4.5 (Tôi tin).
MSDN tài liệu cho Code Access Security Basics trạng thái:
.NET Framework cung cấp một cơ chế cho việc thi hành mức độ khác nhau của sự tin tưởng vào đoạn mã khác nhau chạy trong cùng một ứng dụng gọi là Mã bảo mật truy cập (CAS). Không được sử dụng bảo mật truy cập mã trong .NET Framework như một cơ chế để thực thi các ranh giới bảo mật dựa trên mã nguồn hoặc các khía cạnh nhận dạng khác. Chúng tôi đang cập nhật hướng dẫn của mình để phản ánh rằng Mã bảo mật truy cập và mã bảo mật trong suốt sẽ không được hỗ trợ dưới dạng ranh giới bảo mật có mã đáng tin cậy một phần, đặc biệt là mã không rõ nguồn gốc. Chúng tôi khuyên bạn không nên tải và thi hành mã nguồn gốc không xác định mà không đặt các biện pháp bảo mật thay thế.
Và sau đó trỏ đến trang cho Security Changes in the .NET Framework trong đó nêu:
Sự thay đổi quan trọng nhất đối với an ninh trong .NET Framework 4.5 là trong đặt tên mạnh.
Mà sau đó trỏ tới tài liệu cho Enhanced Strong Naming trong đó nêu:
phím tên mạnh bao gồm một phím chữ ký và một chìa khóa sắc. Việc lắp ráp được ký với phím chữ ký và được xác định bằng khóa nhận dạng.Trước .NET Framework 4.5, hai khóa này giống hệt nhau. Bắt đầu với .NET Framework 4.5, khóa nhận dạng vẫn giữ nguyên như trong các phiên bản .NET Framework trước đó, nhưng khóa chữ ký được tăng cường bằng thuật toán băm mạnh hơn. Ngoài ra, phím chữ ký được ký với khóa nhận dạng để tạo chữ ký chống lại.
CŨNG, tài liệu cho Secure Coding Guidelines trạng thái:
Mã bảo mật truy cập và Mã bảo vệ-Transparent sẽ không được hỗ trợ như là một ranh giới an ninh với mã tin cậy một phần. Chúng tôi khuyên bạn không nên tải và thi hành mã nguồn gốc không xác định mà không đặt các biện pháp bảo mật thay thế tại chỗ ...
Vì vậy, mô hình bảo mật cho .NET đã thay đổi năm trước, nhưng SQL Server (cho đến SQL Server 2017) đã được cho phép để tiếp tục sử dụng mô hình bảo mật cũ. Dường như, bắt đầu với SQL Server 2017, quyết định đã được thực hiện để không còn hỗ trợ mô hình bảo mật cũ.
tôi nghi ngờ rằng việc cho phép các mô hình bảo mật cũ là:
ngăn chặn SQL Server (ít nhất là CLR liên quan đến chức năng/thành phần) không bị dựa trên các phiên bản .NET Framework mới hơn, và
chịu trách nhiệm cho việc loại bỏ đột ngột SQLCLR dưới dạng tính năng được hỗ trợ từ Cơ sở dữ liệu SQL Azure (hỗ trợ đã được thêm vào cuối năm 2014 với sự ra mắt của v12, nhưng sau đó bị loại bỏ hoàn toàn kể từ ngày 15 tháng 4 năm 2016).
Vì vậy, vâng, điều này kinda sucks. Điều đó có nghĩa là cần phải trước tiên tạo Chứng chỉ hoặc Khóa bất đối xứng (được sử dụng để ký bất kỳ Tập hợp nào) vào [master] để sau đó tạo Đăng nhập và sau đó cấp UNSAFE ASSEMBLY cho Đăng nhập đó. Đây là cùng một chuỗi sự kiện mà một người cần làm khi tải EXTERNAL_ACCESS và UNSAFE Hội đồng, nhưng giờ đây, thật không may, cần phải được thực hiện ngay cả khi SAFE Hội đồng.
Hiện tại không có cơ chế để xử lý điều này theo cách hoàn toàn di động (tức là không dựa vào các tệp bên ngoài) và không thể xử lý bởi Visual Studio/SSDT mà không có sự can thiệp thủ công. Đây là trường hợp đã xảy ra, nhưng ít nhất có thể tạo ra một thiết lập để xử lý điều này theo kiểu hoàn toàn di động (tức là hoàn toàn nằm trong một tập lệnh .sql): vui lòng xem Stairway to SQLCLR Level 7: Development and Security để biết chi tiết (đây là một bài viết mà tôi đã viết)).
Có thể tạo một chứng chỉ từ byte hex (ví dụ: FROM BINARY = 0x...) nhưng điều đó không làm việc với Visual Studio (mà dựa vào MSBuild)/SSDT kể từ khi sử dụng Giấy chứng nhận đòi hỏi phải sử dụng signtool và MSBuild sử dụng sn.
Để thực hiện điều này, quy trình xuất bản Visual Studio/MSBuild/SSDT hoạt động (điều này có nghĩa là bất kỳ ai cũng có thể tạo tập lệnh .sql hoàn toàn độc lập có khả năng tạo đối tượng không đối xứng Khóa mà không dựa vào một tệp bên ngoài), lệnh CREATE ASYMMETRIC KEY cần được tăng cường để cho phép được tạo từ một chuỗi nhị phân. Tôi đã thực hiện đề xuất này trên Microsoft Connect – Allow Asymmetric Key to be created from binary hex bytes string just like CREATE CERTIFICATE – vì vậy hãy hỗ trợ nó :-).Ngoài ra, (cho đến thời điểm này, cho đến khi MS hy vọng tạo ra một phương pháp tốt hơn, chẳng hạn như các đề xuất không đối xứng), bạn có thể thử một trong hai kỹ thuật tôi mô tả trong các bài đăng trên blog sau đây (cả hai hoạt động hoàn toàn với SSDT):
Như một phương sách cuối cùng, bạn có thể xem xét các phương pháp sau đây:
- TẠM thiết lập cơ sở dữ liệu
[master]-TRUSTWORTHY ON
- Tạo hội trong
[master]
- Tạo Key không đối xứng từ hội
- Drop hội
- thiết lập cơ sở dữ liệu
[master]-TRUSTWORTHY OFF
- Tạo Đăng nhập từ Khóa Không đối xứng
- Grant
UNSAFE ASSEMBLY để đăng nhập mà
Xin lưu ý rằng tôi đã làm không bao gồm tính năng mới "Trusted hội" tính năng như một tùy chọn ở đây. Lý do nó không được đề cập là do nó có nhiều lỗ hổng hơn lợi ích, chưa kể nó hoàn toàn không cần thiết ngay từ đầu cho rằng chức năng hiện tại đã xử lý tình huống "Hội đồng tin cậy" có nghĩa là giải quyết. Để biết chi tiết đầy đủ về điều đó và bản trình diễn về cách thích hợp để xử lý các Hội đồng hiện có, chưa ký, vui lòng xem: SQLCLR vs. SQL Server 2017, Part 4: “Trusted Assemblies” – The Disappointment.
Rất đẹp blog-bưu điện, cảm ơn bạn rất nhiều. Vì vậy, bạn nghĩ rằng câu "có thể truy cập tài nguyên hệ thống bên ngoài, gọi mã không được quản lý, và có được đặc quyền sysadmin" là không chính xác. Có lẽ bạn cần phải làm một cái gì đó lạ mắt và kỳ lạ để vượt qua các kiểm tra an ninh –
Hi Jesus! Yeah - Tôi nghĩ nó không chính xác, ít nhất là không dựa trên thử nghiệm của tôi. –