Có cách nào để chặn một C# plugin truy cập vào ứng dụng C# chính trong một chương trình không?

Question

Tôi có một chương trình và một kiến ​​trúc plugin đơn giản, nơi các plugin thực hiện một giao diện chung và chương trình chính tải tất cả các plugin thực hiện giao diện này. Đó là kiến ​​trúc plugin tùy chỉnh phổ biến nhất mà tôi đã tìm thấy từ trước đến nay, vì vậy đó là những gì tôi đang sử dụng.

Tôi không sử dụng MEF của Microsoft và tôi có lý do không làm như vậy. Tôi sẽ để nó ở đó.

Vấn đề là khi các plugin được tải, bất kể chúng 'mù' đến chương trình chính và đó là các biểu mẫu/lớp/v.v. nó vẫn có thể truy cập System.Windows.Forms.Application và do đó có thể truy cập vào ứng dụng của tôi và các biểu mẫu/phương thức/điều khiển/v.v. hiện đang chạy của nó.

Tôi không muốn điều này. Có cách nào để hạn chế quyền truy cập của một plugin vào Ứng dụng chính không?

EDIT: Thông tin thêm về các plugin

Chúng tôi (ông chủ của tôi và tôi) hiện đang thảo luận những gì các plugins cần phải làm. Tất cả chúng rõ ràng là cần thêm chức năng, nhưng ban đầu chúng tôi quyết định cấp cho mỗi plugin quyền truy cập vào biểu mẫu hiện đang chạy để có thể thêm điều khiển và sự kiện trực tiếp vào biểu mẫu. Điều này được dựa trên giả định rằng chỉ có chúng tôi, các nhà phát triển, sẽ viết chúng.

Hiện tại, chúng tôi đang cân nhắc khả năng plugin của bên thứ ba và thiết kế ban đầu, có độ bảo mật cao như dấu "Không nhập" trên cửa mở mà không có ai xung quanh.

Hoặc dấu "Take One" treo trên một bát skittles riêng lẻ vào Halloween.

Answer 1

Một cách để thực hiện việc này là lưu trữ các plugin của bạn trong AppDomains của riêng chúng. Bạn có thể cấu hình các AppDomain này để bảo mật hạn chế để ngăn chặn chúng truy cập tài nguyên trong AppDomain chính. Điều này làm phức tạp mọi thứ rất nhiều, nhưng sẽ cung cấp cho bạn cát-boxing bạn sau.

Một lợi ích bổ sung mà bạn nhận được từ lưu trữ AppDomain là bạn có thể tải và dỡ các miền này nếu bạn muốn làm mới các plugin, ngoài ra bạn có thể bảo vệ AppDomain chính của bạn khỏi sự cố trong miền "con".

Cập nhật

Sau khi nhìn thấy cập nhật lại của bạn. khả năng của plugin của bạn, AppDomains sẽ không trợ giúp nếu plugin của bạn phải có quyền truy cập trực tiếp vào các yếu tố giao diện người dùng, ví dụ: truy cập vào biểu mẫu để thêm điều khiển. Bạn sẽ không thể cung cấp quyền truy cập trực tiếp vào biểu mẫu qua ranh giới AppDomain hoặc tạo các điều khiển trong một AppDomain và sau đó sắp xếp chúng qua một AppDomain khác. Bạn vẫn có thể xem xét việc lưu trữ plugin trong một AppDomain khác, nhưng bạn sẽ cần phải suy nghĩ về một số loại cơ chế proxy để các hành động như thêm một điều khiển vào biểu mẫu có thể được thực hiện thay mặt cho một plugin, thay vì cho phép plugin truy cập trực tiếp vào biểu mẫu. Ví dụ, bạn có thể truyền vào một đối tượng trình tạo biểu mẫu có các phương thức như AddButton. Sau đó, proxy có thể thực hiện các tác vụ này thay mặt cho plugin trong miền chính. Bằng cách này, bạn có thể cung cấp một API giới hạn cho plugin hoàn chỉnh với các sự kiện được yêu cầu.

Cách tiếp cận này không có nghĩa là tầm thường, nhưng một khi bạn đã nắm vững các khái niệm cơ bản thì nó không quá phức tạp.

Cập nhật 2

Mọi thứ đã chuyển từ lăn khung Plugin của riêng bạn với AppDomins trở lại trong ngày. Có hiện đang hỗ trợ nướng vào khuôn khổ Net từ 3,5 cho plugin:

MAF - Managed Addin Framework/System.Addin

Nó hỗ trợ chế độ cách ly AppDomain cho plugin và có bộ tải plugin, vv Không cần phải cuộn của riêng bạn.

Answer 2

Nếu bạn có thể chạy các plugin của mình theo cách riêng của mình AppDomains, điều đó chắc chắn sẽ làm tăng mức độ cô lập. Nó cũng có thể làm cho nó một nỗi đau để giao tiếp với họ mặc dù. Nếu không biết thêm về những gì các plugin có nghĩa là để làm, thật khó để biết có thích hợp hay không.

Answer 3

Cách tốt nhất để xử lý việc này là hiển thị API plugin được ghi nhận. Nếu plugin của bạn chạy với sự tin tưởng hoàn toàn, thì ngay cả khi bạn chạy plugin trong AppDomain của chính nó, nó có thể tự tiêm ngược lại vào ứng dụng - sau đó tất cả những gì cần làm là một trình bao bọc có sẵn và tất cả các plugin đều trở lại trạng thái giống nhau bắt đầu vào. Nếu API của bạn cho phép các plugin cung cấp các tính năng mong muốn theo cách đơn giản, nhất quán và được ghi lại, thì đó là những gì các nhà phát triển plugin sẽ sử dụng.

Sau đây là các móc giao diện người dùng bên ngoài cho WPF, Biểu mẫu Windows và Spy ++ cổ điển (tất cả đều có nguồn).

• Snoop (the WPF Spy)
• Managed Spy
• .NET Object Spy and InvokeRemote
• Win Spy++

Answer 4

Vì vậy, để xác định lại mối quan tâm chính của bạn:

... và do đó có thể được truy cập vào ứng dụng của tôi và nó là hiện đang chạy các biểu mẫu/phương thức/điều khiển/v.v.

Trước khi bắt tay vào một phương tiện tải phức tạp và khó khăn, cách ly và hạn chế các tiện ích này, bạn nên biết một số điều về Windows và CLR. Đầu tiên, bất kỳ chương trình nào chạy trên hộp đều có thể sử dụng một số API Windows để chèn mã vào quy trình của bạn. Khi mã được nạp vào quá trình của bạn, hoặc bởi bạn hoặc bởi hệ điều hành, truy cập vào thời gian chạy CLR và các assembly tải và/hoặc chạy mã trong AppDomain hiện tại của bạn là khá dễ dàng.

Biết điều này bạn nên cân nhắc và cân bằng nỗ lực bạn trích dẫn để hạn chế 'tiện ích mở rộng'. Nếu tôi xây dựng một cái gì đó như thế này tôi sẽ quan tâm nhiều hơn về những thứ khác hơn là một đoạn mã mở rộng độc hại điều khiển trạng thái của ứng dụng của tôi. Ví dụ: đây là những điều bạn có thể xem xét:

1. Chỉ tiện ích mở rộng tải được chấp thuận bởi người dùng của bạn, cho phép họ kiểm soát nội dung được phép và cho phép họ thu hồi tiện ích mở rộng sau này nếu muốn. Hãy xem Office hoặc VStudio làm ví dụ.
2. Đảm bảo các tiện ích mở rộng được chấp thuận này không được hỗ trợ bằng cách sử dụng yêu cầu ký mã (tên mạnh hoặc chứng chỉ ký mã).
3. Cân nhắc khả năng thu hồi khả năng chạy của tiện ích mở rộng từ xa nếu phát hiện thấy nó độc hại.
4. Chứng minh API giao diện được chỉ định để cho phép nhà phát triển dễ dàng thực hiện hành vi mong muốn. Nếu họ dễ dàng sử dụng giao diện của bạn để hoàn thành nhiệm vụ của họ, họ sẽ không cần phải 'hack'.

Ngoài việc này, bạn không thể làm được gì nhiều. Như tôi đã nói, bất kỳ ai cũng có thể tấn công ứng dụng của bạn ngay cả với những người bảo vệ an toàn ở trên. Mối quan tâm chính của bạn là không làm người dùng ngạc nhiên. Do đó, việc quan tâm đến việc mã ứng dụng của bạn chạy là gì, nhưng những gì các phần mở rộng đó làm khi người dùng cấp quyền truy cập cho họ không thực sự là điều bạn hoàn toàn có thể kiểm soát.

Điều này không có nghĩa là cách ly AppDomain sẽ không cung cấp cho bạn giá trị, nó có thể; Tuy nhiên, IMHO nhận được an ninh hạn chế đủ mà không hạn chế khả năng hoạt động của họ sẽ chứng minh là khó khăn.

CẬP NHẬT

... nhưng nếu bạn nạp một plugin vào một AppDomain được cấu hình với các điều khoản hạn chế như thế nào nó có thể sử dụng vector này?

Đúng, như tôi đã nói trong báo cáo kết thúc, bạn có thể giới hạn quyền truy cập của họ vào mã không được quản lý trong AppDomain. Điều này cũng hạn chế khả năng phát triển trải nghiệm Windows có thể sử dụng của họ. Tôi hy vọng rằng hầu hết các ứng dụng WinForms sử dụng ít nhất một cuộc gọi PInvoke hoặc điều khiển COM không được quản lý. Giới hạn này có thể được chấp nhận, tôi thực sự không thể nói mà không có thêm thông tin về chức năng mà họ đang cố gắng cung cấp.

Tất cả những gì tôi đang cố gắng nói là bằng cách cài đặt và phê duyệt tiện ích, người dùng của bạn chấp nhận trách nhiệm cho phép tiện ích đó chạy. Phần mở rộng đó là gì và mức độ nguy hiểm của nó có thể không phải là trách nhiệm của bạn, giả sử tất nhiên là bạn đã tải đúng mã. Đây là lý do tại sao tôi khuyên bạn nên tập trung năng lượng của mình vào việc chạy mã được phê duyệt thay vì lo lắng về mã đó có thể làm gì khi nó đang trong quá trình của bạn.