Các giải pháp lập trình CSharp- P63

Chia sẻ: Cong Thanh | Ngày: | Loại File: PDF | Số trang:10

Thêm vào BST

Báo xấu

66
lượt xem 12
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Các giải pháp lập trình CSharp- P63: Các giải pháp lập trình C# khảo sát chiều rộng của thư viện lớp .NET Framework và cung cấp giải pháp cụ thể cho các vấn đề thường gặp. Mỗi giải pháp được trình bày theo dạng “vấn đề/giải pháp” một cách ngắn gọn và kèm theo là các ví dụ mẫu.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Các giải pháp lập trình CSharp- P63

511 Chương 13: Bảo mật M ục tiêu chính của Microsoft .NET Framework là làm cho việc lập trình trở nên an toàn hơn—đặc biệt lưu tâm đến việc sử dụng mobile code5 và các hệ thống phân tán. Hầu hết các hệ điều hành hiện đại (bao gồm Microsoft Windows) đều hỗ trợ bảo mật dựa-trên-người-dùng (User-Based Security), cho phép bạn kiểm soát các hành động và các tài nguyên mà một người dùng truy xuất đến. Tuy nhiên, do sự phát triển của mạng máy tính, đặc biệt là Internet, sự bảo mật nếu chỉ dựa vào định danh của người dùng trên hệ thống là chưa đủ. Khi quan tâm đến bảo mật, mã lệnh không nên tự động nhận mức tin cậy như mức tin cậy mà bạn đã ấn định cho người đang chạy mã lệnh này. .NET Framework kết hợp hai mô hình bảo mật bổ sung lẫn nhau (thực hiện nhiều vấn đề liên quan đến bảo mật người dùng và mã lệnh): • CAS (Code Access Security—Bảo mật truy xuất mã lệnh) • RBS (Role-Based Security—Bảo mật dựa-trên-vai-trò) CAS và RBS không thay thế hay sao lại các phương tiện bảo mật do hệ điều hành nằm dưới cung cấp. Chúng là các cơ chế độc lập nền, cấp thêm các khả năng bảo mật để nâng cao tính bảo mật tổng thể trong các giải pháp được-quản-lý. CAS sử dụng các thông tin về nguồn gốc của một assembly đã được thu thập lúc thực thi—đây là chứng cứ (evidence)—để xác định xem mã lệnh có thể truy xuất các hành động và tài nguyên nào—đây là quyền (permission). Chính sách bảo mật của .NET Framework—một tập hợp phân cấp các quy tắc cấu hình—định nghĩa phép ánh xạ giữa chứng cứ và quyền. Thư viện lớp .NET Framework sử dụng các yêu cầu quyền (permission demand hay permission request) để bảo vệ các chức năng quan trọng nhất của nó không bị truy xuất trái phép. Một yêu cầu buộc bộ thực thi bảo đảm rằng: nếu muốn gọi một phương thức được-bảo-vệ thì mã lệnh phải có một quyền cụ thể nào đó. CAS bảo đảm rằng: khả năng thực thi của mã lệnh tùy thuộc vào mức độ tin cậy của bạn đối với người tạo ra mã và nguồn gốc của nó, chứ không phải mức độ tin cậy đối với người dùng đang chạy mã. Các mục liên quan đến CAS trong chương này thảo luận các vấn đề sau:  Cho phép mã lệnh có-độ-tin-cậy-một-phần (partially trusted code) truy xuất các assembly tên mạnh của bạn (mục 13.1).  Vô hiệu hoàn toàn CAS (mục 13.2) hoặc chỉ vô hiệu việc kiểm tra quyền thực thi (mục 13.3).  Yêu cầu các quyền truy xuất mã lệnh cụ thể và xác định xem bộ thực thi đã cấp các quyền nào cho mã lệnh của bạn (mục 13.4, 13.5, 13.6, và 13.7).  Kiểm soát sự thừa kế và chép đè thành viên bằng CAS (mục 13.8).  Xem xét và xử lý chứng cứ của assembly (mục 13.9 và 13.10).  Xử lý bảo mật bộ thực thi bằng miền ứng dụng (mục 13.11 và 13.12). RBS cho phép bạn thực hiện các quyết định lúc thực thi (runtime decision) dựa trên định danh (identity) và các vai trò (role) của người dùng mà ứng dụng đang chạy trên danh nghĩa người dùng này. Trên hệ điều hành Windows, đây chính là việc thực hiện các quyết định dựa trên tên người dùng Windows và các nhóm Windows mà người dùng đó thuộc về. Tuy nhiên, RBS 5 Mobile code là phần mềm được truyền qua một hệ thống mạng và sau đó được thực thi trên hệ thống cục bộ.
512 Chương 13: Bảo mật cung cấp một cơ chế bảo mật chung không lệ thuộc vào hệ điều hành nằm dưới, cho phép bạn tích hợp vào bất kỳ hệ thống tài khoản người dùng nào. Các mục trong chương này thảo luận các vấn đề sau đây của .NET RBS:  Tích hợp RBS với các tài khoản người dùng Windows và xác định xem một người dùng có là thành viên của một nhóm Windows nào đó hay không (mục 13.13).  Kiểm soát việc truy xuất đến các chức năng của ứng dụng dựa trên người dùng hiện hành và các vai trò mà người dùng này là một thành viên (mục 13.14).  Giả nhận một người dùng Windows để thực hiện các tác vụ hệ điều hành trên danh nghĩa người dùng đó (mục 13.15). Các mục liên quan đến RBS và CAS trong chương này trình bày một số công việc thông thường mà bạn sẽ cần thực hiện trong các ứng dụng, nhưng chúng chỉ mô tả một phần nhỏ trong các khả năng bảo mật của .NET Framework. Để hiểu rõ hơn, bạn hãy tham khảo một quyển sách khác chuyên về bảo mật trong .NET Framework. 1. Cho phép mã lệnh có-độ-tin-cậy-một-phần sử dụng assembly tên mạnh của bạn  Bạn cần viết một assembly chia sẻ sao cho nó là khả truy xuất đối với mã lệnh có-độ-tin-cậy-một-phần (theo mặc định, bộ thực thi không cho phép mã lệnh có- độ-tin-cậy-một-phần truy xuất các kiểu và các thành viên nằm trong một assembly tên mạnh).  Áp dụng đặc tính System.Security.AllowPartiallyTrustedCallersAttribute cho assembly chia sẻ của bạn. Để giảm thiểu các nguy cơ bảo mật do mã lệnh nguy hiểm bày ra, bộ thực thi không cho phép các assembly có-độ-tin-cậy-một-phần truy xuất đến các assembly tên mạnh. Hạn chế này làm giảm nguy cơ mã lệnh nguy hiểm tấn công vào hệ thống của bạn, nhưng đối với một cách tiếp cận áp chế như thế cần phải có lời giải thích. Theo quy tắc, các assembly tên mạnh được cài đặt trong Global Assembly Cache (GAC) và chứa các chức năng quan trọng được dùng chung giữa nhiều ứng dụng. Điều này hoàn toàn đúng với các assembly cấu thành thư viện lớp .NET Framework. Các assembly tên mạnh khác từ các sản phẩm được-phân-bổ-rộng-rãi cũng sẽ nằm trong GAC và là khả truy xuất đối với các ứng dụng được-quản-lý. Khả năng hiện diện trong GAC cao, tính khả truy xuất dễ dàng, và tầm quan trọng đối với nhiều ứng dụng khác nhau khiến cho các assembly tên mạnh là mục tiêu có khả năng nhất đối với bất cứ hành động phá hoại nào của mã lệnh nguy hiểm được- quản-lý. Thông thường, mã lệnh có khả năng nguy hiểm là mã được nạp từ các nơi xa—như Internet— ở đó bạn có ít (hay không có) sự kiểm soát nào. Với chính sách bảo mật mặc định, tất cả mã lệnh chạy từ máy cục bộ đều có độ tin cậy toàn phần (full trust), trong khi mã lệnh được nạp từ các nơi xa chỉ có độ tin cậy một phần (partial trust). Ngăn mã lệnh có-độ-tin-cậy-một-phần truy xuất đến các assembly tên mạnh; nghĩa là mã lệnh có-độ-tin-cậy-một-phần không có cơ
513 Chương 13: Bảo mật hội sử dụng các tính năng của assembly cho các mục đích nguy hiểm, và không thể khảo sát assembly để tìm các lỗ hổng có thể khai thác được. Dĩ nhiên, lý thuyết này giả định rằng bạn quản lý chính sách bảo mật một cách phù hợp. Nếu bạn gán tất cả mã lệnh có độ tin cậy toàn phần, không chỉ bất kỳ assembly nào cũng có thể truy xuất assembly tên mạnh của bạn, mà mã lệnh này còn có thể truy xuất tất cả các chức năng của .NET Framework. Điều này sẽ là một tai họa bảo mật!  Nếu bạn thiết kế, hiện thực, và thử nghiệm assembly chia sẻ của bạn một cách phù hợp bằng CAS để giới hạn việc truy xuất đến các thành viên quan trọng, bạn không cần áp đặt một hạn chế bao trùm để ngăn mã lệnh có-độ-tin-cậy-một- phần sử dụng assembly của bạn. Tuy nhiên, đối với một assembly bất kỳ, không thể chứng minh rằng không có lỗ hổng bảo mật nào để mã nguy hiểm có thể lợi dụng. Do đó, bạn nên xem xét cẩn thận nhu cầu cho phép mã lệnh có-độ-tin-cậy- một-phần truy xuất assembly tên mạnh trước khi áp dụng đặc tính AllowPartiallyTrustedCallersAttribute. Bộ thực thi ngăn mã lệnh có-độ-tin-cậy-một-phần truy xuất các assembly tên mạnh bằng cách đặt LinkDemand vào tập quyền FullTrust trên mọi thành viên công-khai (public) và được-bảo- vệ (protected) của mỗi kiểu khả-truy-xuất-công-khai được định nghĩa trong assembly. Điều này có nghĩa là chỉ những assembly được cấp các quyền tương đương với tập quyền FullTrust thì mới có thể truy xuất các kiểu và thành viên trong assembly tên mạnh. Việc áp dụng AllowPartiallyTrustedCallersAttribute vào assembly tên mạnh báo với bộ thực thi không buộc LinkDemand có hiệu lực trên các thành viên và các kiểu bên trong.  Bộ thực thi chịu trách nhiệm buộc các hoạt động bảo mật ngầm LinkDemand có hiệu lực để bảo vệ các assembly tên mạnh; C# assembler không sinh ra các lệnh khai báo LinkDemand lúc biên dịch. Đoạn mã dưới đây trình bày một ứng dụng có sử dụng đặc tính AllowPartiallyTrustedCallersAttribute. Chú ý rằng, bạn phải sử dụng tiền tố assembly: để báo với trình biên dịch rằng đích của đặc tính này là assembly (còn được gọi là đặc tính toàn cục—global attribute). Ngoài ra, không cần thêm phần Attribute vào tên của đặc tính—mặc dù bạn có thể thêm vào nếu muốn. Vì bạn nhắm đến assembly nên đặc tính này phải được đặt sau các lệnh using mức trên, nhưng trước các khai báo không gian tên và kiểu. using System.Security; [assembly:AllowPartiallyTrustedCallers] public class AllowPartiallyTrustedCallersExample { § }  Thực tế, tất cả các đặc tính toàn cục đều nằm trong một file độc lập với phần mã lệnh còn lại của ứng dụng. Microsoft Visual Studio .NET sử dụng cách tiếp cận này: tạo một file có tên là AssemblyInfo.cs để chứa tất cả các đặc tính toàn cục.
514 Chương 13: Bảo mật Nếu sau khi áp dụng AllowPartiallyTrustedCallersAttribute cho assembly, bạn muốn mã lệnh có-độ-tin-cậy-một-phần chỉ gọi được một số thành viên nào đó, bạn cần bổ sung LinkDemand cho tập quyền FullTrust trên các thành viên cần thiết, như được trình bày trong đoạn mã dưới đây: [System.Security.Permissions.PermissionSetAttribute (System.Security.Permissions.SecurityAction.LinkDemand, Name="FullTrust")] public void SomeMethod() { § } 2. Vô hiệu bảo mật truy xuất mã lệnh  Bạn cần vô hiệu CAS.  Thiết lập thuộc tính SecurityEnabled của lớp System.Security.SecurityManager là false và lưu lại bằng phương thức SecurityManager.SavePolicy. Bạn cũng có thể sử dụng công cụ Code Access Security Policy (Caspol.exe) và thực thi lệnh caspol –s off. CAS là phần then chốt trong mô hình bảo mật của bộ thực thi .NET, và cũng là phần đặc trưng của nền tảng .NET mà nhiều nền tảng khác không có. Mặc dù CAS được xây dựng với tiêu chí đảm bảo hiệu năng thực thi cao nhất và đã được sử dụng một cách cẩn trọng trong thư viện lớp .NET, nhưng vẫn có một chi phí cho mỗi yêu cầu bảo mật (security demand) và stack walk (kết quả) mà bộ thực thi phải thực hiện. Đôi lúc, bảo mật mức-mã-lệnh có thể không là điều bạn bận tâm, hoặc nhu cầu hiệu năng có thể vượt quá nhu cầu CAS. Trong các trường hợp này, bạn có thể vô hiệu hoàn toàn CAS và loại bỏ chi phí cho việc kiểm tra bảo mật mức-mã-lệnh. Vô hiệu CAS có tác dụng trao cho mã lệnh khả năng thực hiện bất kỳ hành động nào mà .NET Framework hỗ trợ (tương đương với tập quyền FullTrust), bao gồm khả năng nạp mã lệnh khác, gọi các thư viện nguyên sinh, và sử dụng con trỏ để trực tiếp truy xuất bộ nhớ.  Bạn chỉ nên vô hiệu CAS vì các lý do hiệu năng sau khi đã tiêu hết tất cả các chừng mực có thể khác để đạt được các đặc điểm hiệu năng mà ứng dụng của bạn đòi hỏi. Việc lập profile cho mã lệnh thường sẽ nhận biết những vùng mà bạn có thể cải thiện đáng kể hiệu năng nhưng không phải vô hiệu CAS. Ngoài ra, bạn cần bảo đảm các tài nguyên hệ thống đã được bảo vệ bằng các cơ chế bảo mật của hệ điều hành (như Windows ACLs) trước khi vô hiệu CAS. Caspol.exe là một tiện ích được cấp cùng với .NET Framework, cho phép bạn cấu hình chính sách bảo mật truy xuất mã lệnh từ dòng lệnh. Khi bạn nhập lệnh caspol –s off hoặc caspol –s on, tiện ích này sẽ xác lập thuộc tính SecurityEnabled của lớp SecurityManager. Lớp SecurityManager cung cấp tập các phương thức tĩnh để truy xuất dữ liệu và chức năng bảo
515 Chương 13: Bảo mật mật quan trọng. Đoạn mã dưới đây trình bày cách sử dụng thuộc tính SecurityEnabled để vô hiệu và kích hoạt CAS: // Vô hiệu CAS. System.Security.SecurityManager.SecurityEnabled = false; // Lưu cấu hình. System.Security.SecurityManager.SavePolicy(); // Kích hoạt CAS. System.Security.SecurityManager.SecurityEnabled = true; // Lưu cấu hình. System.Security.SecurityManager.SavePolicy(); Để vô hiệu CAS, mã lệnh của bạn phải có phần tử ControlPolicy của System.Security.Permissions.SecurityPermission. Để kích hoạt CAS, bạn không cần phải có quyền cụ thể nào. Thay đổi SecurityEnabled sẽ không ảnh hưởng đến hoạt động của CAS trong các tiến trình hiện có, và cũng không ảnh hưởng đến các tiến trình mới cho đến khi bạn gọi phương thức SavePolicy để lưu trạng thái của SecurityEnabled vào Windows Registry. Đáng tiếc, .NET Framework không bảo đảm những thay đổi của SecurityEnabled sẽ tác động đúng đến hoạt động của CAS trong tiến trình hiện hành. Do đó, bạn phải thay đổi SecurityEnabled rồi mở một tiến trình mới để có được hoạt động đúng như mong muốn. Hình 13.1 Registry Editor (CAS đã bị vô hiệu)  Trạng thái hiện hành của CAS (on/off) được lưu trong khóa HKEY_ LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\Security\Policy của Windows Registry. Nếu khóa này không tồn tại, mặc định CAS là on.
516 Chương 13: Bảo mật 3. Vô hiệu việc kiểm tra quyền thực thi  Bạn cần ngăn bộ thực thi kiểm tra mỗi assembly được nạp vào có quyền thực thi (execution permission) hay không.  Thiết lập thuộc tính CheckExecutionRights của lớp System.Security. SecurityManager là false rồi lưu lại bằng phương thức SecurityManager. SavePolicy. Bạn cũng có thể sử dụng công cụ Code Access Security Policy (Caspol.exe) và thực thi lệnh caspol –e off. Mỗi khi nạp assembly, bộ thực thi bảo đảm grant-set của assembly này có chứa phần tử Execution của SecurityPermission. Bộ thực thi hiện thực một quá trình phân giải chính sách “lười” (lazy policy resolution process), nghĩa là grant-set của một assembly không được tính cho đến khi có một yêu cầu bảo mật (security demand) được thực hiện trên assembly này. Việc kiểm tra quyền thực thi không chỉ buộc bộ thực thi kiểm tra mỗi assembly có quyền thực thi hay không, mà còn gián tiếp tạo ra việc phân giải chính sách đối với mỗi assembly được nạp, phủ nhận lợi ích của việc phân giải chính sách “lười”. Các yếu tố này có thể gây ra sự trì hoãn đáng kể khi các assembly được nạp, đặc biệt khi bộ thực thi nạp nhiều assembly cùng một lúc. Trong nhiều trường hợp, việc cho phép mã lệnh nạp và chạy không phải là một nguy cơ đáng kể miễn là tất cả các hoạt động và các tài nguyên quan trọng khác đã được bảo vệ bằng CAS và bằng cơ chế bảo mật của hệ điều hành. Bộ thực thi .NET cho phép bạn vô hiệu việc tự động kiểm tra các quyền thực thi ngay bên trong mã lệnh, hay bằng công cụ Caspol.exe. Khi bạn nhập lệnh caspol –e off hoặc caspol –e on, Caspol.exe sẽ xác lập thuộc tính CheckExecutionRights của lớp SecurityManager. Bạn có thể thực hiện công việc này bên trong mã lệnh như sau: // Vô hiệu việc kiểm tra quyền thực thi. System.Security.SecurityManager.CheckExecutionRights = false; // Lưu cấu hình. System.Security.SecurityManager.SavePolicy(); // Kích hoạt việc kiểm tra quyền thực thi. System.Security.SecurityManager.CheckExecutionRights = true; // Lưu cấu hình. System.Security.SecurityManager.SavePolicy(); Để thay đổi giá trị của CheckExecutionRights thì mã lệnh của bạn phải có phần tử ControlPolicy của SecurityPermission. Thay đổi này sẽ có tác dụng với tiến trình hiện hành ngay tức thì, cho phép bạn nạp các assembly trong lúc thực thi mà bộ thực thi không phải
517 Chương 13: Bảo mật kiểm tra chúng có quyền thực thi hay không. Tuy nhiên, thay đổi này sẽ không ảnh hưởng đến các tiến trình hiện có. Do vậy, bạn phải lưu thay đổi vào Windows Registry (bằng phương thức SavePolicy) để nó có tác dụng với các tiến trình mới. 4. Bảo đảm bộ thực thi cấp cho assembly một số quyền nào đó  Bạn cần bảo đảm bộ thực thi cấp cho assembly của bạn các quyền truy xuất mã lệnh (code access permission) mà các quyền này quyết định sự thành công trong hoạt động của ứng dụng.  Sử dụng các yêu cầu quyền (permission request) để chỉ định các quyền truy xuất mã lệnh mà assembly cần phải có. Bạn khai báo các yêu cầu quyền bằng các đặc tính quyền truy xuất mã lệnh ở mức assembly. Các yêu cầu quyền cho biết các quyền mà mã lệnh phải có thì mới có thể chạy được. Ví dụ, nếu bạn viết một trình xem phim sao cho người dùng có thể sử dụng nó để tải và xem phim từ một server, thật tai hại nếu chính sách bảo mật của người dùng không cho phép chương trình này mở một kết nối mạng đến server. Chương trình của bạn sẽ nạp và chạy, nhưng khi người dùng kết nối đến server để xem phim, chương trình sẽ crash với ngoại lệ System.Security.SecurityException. Giải pháp là đưa vào assembly yêu cầu quyền cần thiết để có thể mở một kết nối mạng đến server (System.Net.WebPermission hay System.Net.SocketPermission, tùy thuộc vào kiểu kết nối bạn cần mở). Bộ thực thi thực hiện các yêu cầu quyền với nguyên tắc: khoan nạp mã lệnh, điều này tốt hơn là nạp mã lệnh và thất bại sau khi thực hiện một hành động mà nó không có quyền. Vì vậy, nếu sau quá trình phân giải chính sách bảo mật, bộ thực thi xác định được grant-set của assembly không thể đáp ứng các yêu cầu quyền của assembly, nó sẽ không nạp assembly và ném ngoại lệ System.Security.Policy.PolicyException. Để khai báo một yêu cầu quyền, bạn phải sử dụng bản sao đặc tính (attribute counterpart) của quyền truy xuất mã lệnh bạn cần. Tất cả các quyền truy xuất mã lệnh đều có một bản sao đặc tính mà bạn có thể sử dụng để tạo ra các lệnh bảo mật khai báo (declarative security statement)—bao gồm các yêu cầu quyền. Ví dụ, bản sao đặc tính của SocketPermission là SocketPermissionAttribute, và bản sao đặc tính của WebPermission là WebPermissionAttribute—Tất cả các quyền và các bản sao đặc tính của chúng cùng theo quy ước đặt tên và là các thành viên của cùng không gian tên. Ứng dụng PermissionRequestExample dưới đây có hai yêu cầu quyền: một cho SocketPermission và một cho SecurityPermission. Bạn cần nhớ các điều sau: • Bạn phải khai báo yêu cầu quyền sau bất kỳ lệnh using mức trên nào nhưng trước bất kỳ khai báo kiểu hay không gian tên nào. • Đặc tính phải nhắm đến assembly nên bạn phải thêm tiền tố assembly: vào tên đặc tính. • Không cần thêm phần Attribute vào tên đặc tính—mặc dù bạn có thể thêm vào nếu muốn. • Bạn phải chỉ định SecurityAction.RequestMinimum là đối số đầu tiên của đặc tính—giá trị này cho biết đây là một yêu cầu quyền.
518 Chương 13: Bảo mật • Bạn phải cấu hình đặc tính để mô tả quyền truy xuất mã lệnh mà bạn cần bằng các thuộc tính của đặc tính. Bạn hãy tham khảo tài liệu .NET Framework SDK để biết thêm chi tiết về các thuộc tính do mỗi đặc tính bảo mật truy xuất mã lệnh hiện thực. • Các lệnh yêu cầu quyền không được kết thúc bằng dấu chấm phẩy (;). • Để tạo nhiều yêu cầu quyền, chỉ cần thêm nhiều lệnh yêu cầu quyền như được trình bày trong ví dụ dưới đây: using System.Net; using System.Security.Permissions; // Yêu cầu SocketPermission (cho phép mở một kết nối // TCP đến host và port được chỉ định). [assembly:SocketPermission(SecurityAction.RequestMinimum, Access = "Connect", Host = "www.fabrikam.com", Port = "3538", Transport = "Tcp")] // Yêu cầu phần tử UnmanagedCode của SecurityPermission, // (kiểm soát khả năng thực thi mã lệnh không-được-quản-lý). [assembly:SecurityPermission(SecurityAction.RequestMinimum, UnmanagedCode = true)] public class PermissionRequestExample { public static void Main() { // Làm gì đó... } } Nếu bạn thực thi ứng dụng PermissionRequestExample và chính sách bảo mật không cấp cho assembly này các quyền được yêu cầu, bạn sẽ nhận được ngoại lệ PolicyException như dưới đây và ứng dụng sẽ không thực thi. Khi sử dụng chính sách bảo mật mặc định, điều này sẽ xảy ra nếu bạn chạy assembly từ một mạng dùng chung vì các assembly được nạp từ Intranet không được cấp SocketPermission. Unhandled Exception: System.Security.Policy.PolicyException: Required permission cannot be acquired. Khi bạn nạp một assembly từ bên trong mã lệnh (tự động hay bằng tay), và assembly này có chứa các yêu cầu quyền mà chính sách bảo mật không đáp ứng thì phương thức mà bạn sử dụng để nạp assembly sẽ ném ngoại lệ PolicyException, do đó bạn phải thụ lý sao cho phù hợp.
519 Chương 13: Bảo mật 5. Giới hạn các quyền được cấp cho assembly  Bạn cần hạn chế các quyền truy xuất mã lệnh được cấp cho assembly của bạn, đảm bảo người khác và phần mềm khác không thể biên mã lệnh của bạn thanh một cơ chế mà thông qua đó để thực hiện các hành động nguy hiểm hay không mong muốn.  Sử dụng các lệnh bảo mật khai báo (declarative security statement) để chỉ định các yêu cầu quyền tùy chọn (optional permission request) và các yêu cầu loại trừ quyền (permission refusal request) trong assembly của bạn. Các yêu cầu quyền tùy chọn định nghĩa tập tối đa các quyền mà bộ thực thi sẽ cấp cho assembly. Các yêu cầu loại trừ quyền chỉ định các quyền cụ thể mà bộ thực thi sẽ không cấp cho assembly. Nếu quan tâm đến bảo mật, thật lý tưởng khi mã lệnh của bạn chỉ có các quyền truy xuất mã lệnh cần thiết để thực hiện chức năng của nó. Điều này giảm thiểu nguy cơ người khác và mã lệnh khác sử dụng mã lệnh của bạn để thực hiện các hành động nguy hiểm hay không mong muốn. Vấn đề là, bộ thực thi phân giải các quyền của một assembly bằng chính sách bảo mật (do một người dùng nào đó hay người quản trị cấu hình). Chính sách bảo mật có thể khác nhau tại mỗi nơi mà ứng dụng chạy, và bạn không thể kiểm soát các quyền mà chính sách bảo mật ấn định cho mã lệnh của bạn. Mặc dù bạn không thể kiểm soát chính sách bảo mật tại tất cả các nơi mà mã lệnh chạy, nhưng .NET Framework cung cấp hai cơ chế mà thông qua đó, bạn có thể loại bỏ các quyền được cấp cho assembly của bạn: yêu cầu loại trừ (refuse request) và yêu cầu tùy chọn (optional request). Yêu cầu loại trừ cho phép bạn chỉ ra các quyền cụ thể mà bạn không muốn bộ thực thi cấp cho assembly. Sau quá trình phân giải chính sách, nếu grant-set của một assembly chứa bất kỳ quyền nào đã được chỉ định trong một yêu cầu loại trừ, bộ thực thi sẽ loại bỏ quyền đó. Yêu cầu tùy chọn định nghĩa tập tối đa các quyền mà bộ thực thi có thể cấp cho assembly. Nếu grant-set của một assembly chứa bất kỳ quyền nào khác với các quyền đã được chỉ định trong yêu cầu tùy chọn, bộ thực thi sẽ loại bỏ quyền đó. Khác với yêu cầu quyền tối thiểu (đã được thảo luận trong mục 13.4), bộ thực thi sẽ không từ chối nạp assembly cua bạn nếu nó không thể cấp tất cả các quyền đã được chỉ định trong yêu cầu tùy chọn. Bạn có thể coi yêu cầu loại trừ và yêu cầu tùy chọn là các cách chọn lựa để thu được cùng kết quả; cách mà bạn sử dụng tùy thuộc vào số lượng quyền bạn muốn loại bỏ. Nếu muốn loại bỏ môt sô ít quyền, bạn hãy chọn yêu cầu loại trừ. Tuy nhiên, nếu muốn loại bỏ nhiều quyền, bạn hãy chọn yêu cầu tùy chọn (yêu câu này gôm một sô quyền bạn cân, phân quyền con lại se tư đông bi loại bo). Bạn thêm các yêu cầu tùy chọn và yêu cầu loại trừ vào mã lệnh bằng các lệnh bảo mật khai báo với cú pháp giống như các yêu cầu quyền tối thiểu đã được thảo luận trong mục 13.4. Điểm khác biệt duy nhất là giá trị của System.Security.Permissions.SecurityAction mà bạn truyền cho phương thức khởi dựng của đặc tính quyền. Sử dụng SecurityAction.RequestOptional để khai báo một yêu cầu tùy chọn và SecurityAction.RequestRefuse để khai báo một yêu cầu loại trừ. Cũng giống như các yêu cầu quyền tối thiểu, bạn phải khai báo các yêu cầu tùy chọn và yêu cầu loại trừ là các đặc tính toàn cục bằng cách thêm tiền tố assembly: vào tên đặc tính. Ngoài ra, tất cả các yêu cầu phải
520 Chương 13: Bảo mật xuất hiện sau bất kỳ lệnh using mức trên nào nhưng trước bất kỳ khai báo kiểu hay không gian tên nào. Ví dụ dưới đây minh họa một yêu cầu quyền tùy chọn cho tập quyền Internet. Đây là tập quyền được định nghĩa bởi chính sách bảo mật mặc định. Khi bộ thực thi nạp OptionalRequestExample, nó sẽ không cấp cho assembly này bất cứ quyền nào không nằm trong tập quyền Internet (tham khảo tài liệu .NET Framework SDK để biết thêm chi tiết về các quyền trong tập quyền Internet). using System.Security.Permissions; [assembly:PermissionSet(SecurityAction.RequestOptional, Name = "Internet")] public class OptionalRequestExample { public static void Main() { // Làm gì đó... } } Trái với OptionalRequestExample, ví dụ dưới đây sử dụng một yêu cầu loại trừ để loại bỏ quyền System.Security.Permissions.FileIOPermission (mô tả quyền truy xuất ghi đối với ổ đĩa C): using System.Security.Permissions; [assembly:FileIOPermission(SecurityAction.RequestRefuse, Write = @"C:\")] public class RefuseRequestExample { public static void Main() { // Làm gì đó... } } 6. Xem các yêu cầu quyền được tạo bởi một assembly  Bạn cần xem các các loại trừ và các yêu cầu quyền khai báo được tạo bên trong một assembly để có thể cấu hình chính sách bảo mật một cách phù hợp, hoặc