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

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—đ

ụ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

M

.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ộ.

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 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

độ-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ơ

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.

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() {

§

}

 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

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.

3. Vô hi u vi c ki m tra quy n th c thi 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

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 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

• 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

5. Gi i h n các quy n đ Gi i h n các quy n đ ớ ạ ớ ạ ề ượ ấ ề ượ ấ c c p cho assembly 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

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 đ Xem các yêu c u quy n đ ầ ầ ề ượ ạ ở ộ ề ượ ạ ở ộ c t o b i m t assembly 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