Xem mẫu
- 1.1 Xử lý bảo mật bộ thực thi
bằng chính sách bảo mật của miền ứng dụng
Bạn cần kiểm soát (bằng mã lệnh) các quyền được cấp cho các assembly.
Cấu hình (bằng mã lệnh) chính sách bảo mật của miền ứng dụng mà bạn đã
nạp các assembly vào đó.
Chính sách bảo mật (security policy) bao gồm bốn mức chính sách: công ty (enterprise),
máy (machine), người dùng (user), và miền ứng dụng (application domain). Bộ thực thi
quyết định những quyền nào để cấp cho một assembly bằng cách xác định tập quyền
được cấp bởi mỗi mức chính sách rồi tính phép giao (phép AND luận lý) của bốn tập
quyền. Các quyền nằm trong tập giao là grant-set cuối cùng của assembly.
Ngay cả khi các mức chính sách công ty, máy, hay người dùng chỉ định code
group LevelFinal (chỉ thị bộ thực thi không đánh giá các mức chính sách thấp
hơn), bộ thực thi luôn sử dụng mức chính sách của miền ứng dụng để tính
grant-set của một assembly.
Chỉ các mức chinh sách công ty, máy, và người dùng là được cấu hình tĩnh bằng
Administrative Tools. Vì miền ứng dụng không tồn tại bên ngoài ngữ cảnh của bộ thực thi
nên không thể cấu hình tĩnh chính sách miền ứng dụng được. Để cấu hình chính sách bảo
mật của một miền ứng dụng, bạn phải tạo một mức chính sách (bằng mã lệnh) rồi gán nó
cho miền ứng dụng.
Xây dựng một mức chính sách bằng mã lệnh có thể là một công việc lâu dài, tùy thuộc
vào độ phức tạp của chính sách bảo mật mà bạn cần diễn tả. Lớp
System.Security.Policy.PolicyLevel mô tả một mức chính sách bảo mật. Bên trong mỗi
đối tượng PolicyLevel, bạn phải tạo dựng một cấu trúc phân cấp các code group, định
nghĩa các điều kiện thành viên, các tập quyền, và các đặc tính của mỗi code group. Có rất
nhiều kiểu được sử dụng để tạo dựng mức chính sách, và thảo luận về các kiểu này là
vượt quá phạm vi quyển sách này. Lập trình bảo mật .NET, như đã đề cập trước đây,
cung cấp thông tin chi tiết về mỗi lớp này và trình bày cách xây dựng một mức chính
sách bằng mã lệnh.
Thông thường, bạn sẽ phát triển một công cụ trợ giúp việc tạo một mức chính
sách và ghi định nghĩa mức chính sách ra file; sau đó, bạn có thể nạp định
nghĩa này từ đĩa khi cần. Lớp PolicyLevel có hai phương thức nhằm đơn giản
hóa quá trình này: ToXml đưa một đối tượng PolicyLevel về dạng dễ lưu trữ,
và FromXml xây dựng lại một đối tượng PolicyLevel từ dạng đã được lưu trữ.
Một khi đã có đối tượng PolicyLevel mô tả chính sách bảo mật như mong muốn, bạn có
thể gán nó cho một miền ứng dụng. Thu lấy tham chiếu System.AppDomain đến miền
ứng dụng mà bạn muốn cấu hình, và truyền đối tượng PolicyLevel cho phương thức
- AppDomain.SetAppDomainPolicy. Mã lệnh của bạn phải có phần tử
ControlDomainPolicy của SecurityPermission thì mới có thể gọi SetAppDomainPolicy.
Bạn chỉ có thể gọi SetAppDomainPolicy một lần trên mỗi miền ứng dụng; nếu bạn gọi
SetAppDomainPolicy lần thứ hai, nó sẽ ném ngoại lệ
System.Security.Policy.PolicyException.
Bạn không phải gán đối tượng PolicyLevel cho một miền ứng dụng trước khi nạp các
assembly vào miền ứng dụng này. Các assembly được nạp trước khi bạn thiết lập chính
sách bảo mật miền ứng dụng có các grant-set chỉ dựa trên các mức chính sách: công ty,
máy, và người dùng. Chính sách miền ứng dụng chỉ áp dụng cho các assembly được nạp
sau khi nó được cấu hình. Thông thường, bạn sử dụng khả năng này để nạp các assembly
chia sẻ đáng-tin-cậy vào miền ứng dụng mà không bị ràng buộc bởi chính sách miền ứng
dụng.
Ứng dụng dưới đây trình bày quá trình tạo một mức chính sách và gán nó cho một miền
ứng dụng. Mức chính sách này cấp các quyền dựa trên publisher của một assembly—
được thể hiện trong các khoản của chứng cứ System.Security.Policy.Publisher.
using System;
using System.Security;
using System.Security.Policy;
using System.Security.Cryptography.X509Certificates;
public class AppDomainPolicyExample {
public static void Main() {
// Tạo một miền ứng dụng mới (để nạp các assembly vào đó).
AppDomain domain = AppDomain.CreateDomain("modules");
// Nạp các assembly vào miền ứng dụng mà bạn không muốn
// bị ràng buộc bởi chính sách bảo mật miền ứng dụng.
§
// Cấu hình chính sách bảo mật cho đối tượng AppDomain.
SetDomainPolicy(domain);
// Nạp các assembly vào miền ứng dụng được bảo vệ.
§
}
- // Phương thức này cấu hình chính sách bảo mật của đối tượng
// AppDomain được truyền cho nó. Chính sách bảo mật sẽ gán các
// quyền khác nhau cho mỗi assembly dựa trên publisher của
// assembly. Những assembly từ các publisher vô danh không được
// cấp quyền nào cả.
private static void SetDomainPolicy(AppDomain domain) {
// Tạo một PolicyLevel mới cho miền ứng dụng.
PolicyLevel policy = PolicyLevel.CreateAppDomainLevel();
// Tạo một FirstMatchCodeGroup mới dùng làm nút gốc của hệ
// thống phân cấp code group. Cấu hình group này sao cho
// nó trùng khớp với tất cả code. Điều này nghĩa là tất cả
// các assembly đều khởi đầu với một grant-set rỗng cho
// mức chính sách miền ứng dụng.
policy.RootCodeGroup = new FirstMatchCodeGroup(
new AllMembershipCondition(),
new PolicyStatement(policy.GetNamedPermissionSet("Nothing"))
);
// Tạo tập các code group để xác định các quyền nào sẽ được cấp
// cho một assembly do một publisher tạo ra. Vì code group gốc
// là một FirstMatchCodeGroup, nên quá trình phân giải chính sách
// chỉ so trùng assembly trên các group con cho đến khi tìm thấy
// trùng khớp đầu tiên. Mỗi code group được tạo với đặc tính
// Exclusive để bảo đảm rằng assembly không lấy thêm quyền
// nào từ các code group khác.
// Tạo code group cấp tập quyền FullTrust cho các
// assembly được phát hành bởi Microsoft.
X509Certificate microsoftCert =
X509Certificate.CreateFromCertFile("microsoft.cer");
policy.RootCodeGroup.AddChild(new UnionCodeGroup(
new PublisherMembershipCondition(microsoftCert),
new PolicyStatement(policy.GetNamedPermissionSet("FullTrust"),
PolicyStatementAttribute.Exclusive)
));
- // Tạo code group cấp tập quyền Internet cho các
// assembly được phát hành bởi Litware, Inc.
X509Certificate litwareCert =
X509Certificate.CreateFromCertFile("litware.cer");
policy.RootCodeGroup.AddChild(new UnionCodeGroup(
new PublisherMembershipCondition(litwareCert),
new PolicyStatement(policy.GetNamedPermissionSet("Internet"),
PolicyStatementAttribute.Exclusive)
));
// Tạo code group cấp tập quyền Execution cho các
// assembly được phát hành bởi Fabrikam, Inc.
X509Certificate fabrikamCert =
X509Certificate.CreateFromCertFile("fabrikam.cer");
policy.RootCodeGroup.AddChild(new UnionCodeGroup(
new PublisherMembershipCondition(fabrikamCert),
new PolicyStatement(policy.GetNamedPermissionSet("Execution"),
PolicyStatementAttribute.Exclusive)
));
// Thêm một code group sau cùng để bắt tất cả các assembly
// không khớp với publisher nào. Gán group này với tập quyền
// Nothing. Vì group này là Exclusive nên assembly sẽ không
// nhận quyền nào từ các group khác, ngay cả từ các
// mức chính sách cao hơn (công ty, máy, và người dùng).
policy.RootCodeGroup.AddChild(new UnionCodeGroup(
new AllMembershipCondition(),
new PolicyStatement(policy.GetNamedPermissionSet("Nothing"),
PolicyStatementAttribute.Exclusive)
));
// Gán chính sách cho miền ứng dụng.
domain.SetAppDomainPolicy(policy);
}
}
- 1.2 Xác định người dùng hiện hành có là thành viên
của một nhóm Windows nào đó hay không
Bạn cần xác định người dùng hiện hành của ứng dụng có phải là thành viên
của một nhóm người dùng Windows nào đó hay không.
Thu lấy đối tượng System.Security.Principal.WindowsIdentity mô tả người
dùng hiện hành bằng phương thức tĩnh WindowsIdentity.GetCurrent. Kế tiếp,
truyền đối tượng WindowsIdentity cho phương thức khởi dựng của lớp
System.Security.Principal.WindowsPrincipal để thu lấy đối tượng
WindowsPrincipal. Cuối cùng, gọi phương thức IsInRole của đối tượng
WindowsPrincipal để xác định người dùng này có nằm trong một nhóm
Windows nào đó hay không.
Cơ chế RBS của .NET Framework trừu tượng hóa các tính năng bảo mật dựa-trên-người-
dùng của hệ điều hành nằm dưới thông qua hai giao diện chính sau đây:
• System.Security.Principal.IIdentity
• System.Security.Principal.IPrincipal
Giao diện IIdentity mô tả thực thể mà mã lệnh hiện đang chạy trên danh nghĩa của thực
thể này, chẳng hạn một người dùng hoặc tài khoản dịch vụ (service account). Giao diện
IPrincipal mô tả IIdentity của thực thể và tập các vai trò mà thực thể này thuộc về. Một
vai trò chỉ là một sự phân loại, dùng để nhóm các thực thể với các khả năng bảo mật
tương tự nhau, chẳng hạn một nhóm người dùng Windows.
Để tích hợp RBS với bảo mật người dùng Windows, .NET Framework cung cấp hai lớp
sau đây (hiện thực giao diện IIdentity và IPrincipal):
• System.Security.Principal.WindowsIdentity
• System.Security.Principal.WindowsPrincipal
Lớp WindowsIdentity hiện thực giao diện IIdentity và mô tả một người dùng Windows.
Lớp WindowsPrincipal hiện thực IPrincipal và mô tả tập các nhóm Windows mà người
dùng này thuộc về. Vì .NET RBS là một giải pháp chung được thiết kế sao cho độc lập
nền, bạn không thể truy xuất các tính năng và các khả năng của tài khoản người dùng
Windows thông qua giao diện IIdentity và IPrincipal, bạn phải sử dụng trực tiếp các đối
tượng WindowsIdentity và WindowsPrincipal.
Để xác định người dùng hiện hành có phải là thành viên của một nhóm Windows nào đó
hay không, trước tiên bạn phải gọi phương thức tĩnh WindowsIdentity.GetCurrent.
Phương thức này trả về một đối tượng WindowsIdentity mô tả người dùng Windows mà
tiểu trình hiện đang chạy trên danh nghĩa của người dùng này. Kế tiếp, tạo một đối tượng
WindowsPrincipal mới và truyền đối tượng WindowsIdentity cho phương thức khởi
dựng. Cuối cùng, gọi phương thức IsInRole của đối tượng WindowsPrincipal để kiểm tra
xem người dùng này có nằm trong một nhóm (vai trò) cụ thể nào đó hay không. IsInRole
- trả về true nếu người dùng này là thành viên của nhóm đã được chỉ định, ngược lại trả về
false.
Bạn có thể thu lấy tham chiếu IPrincipal đến một đối tượng WindowsPrincipal
bằng thuộc tính tĩnh CurrentPrincipal của lớp System.Threading.Thread. Tuy
nhiên, kỹ thuật này tùy thuộc vào cấu hình chính sách principal của miền ứng
dụng hiện hành; mục 13.14 sẽ thảo luận vấn đề này chi tiết hơn.
Phương thức IsInRole có ba phiên bản nạp chồng:
• Phiên bản thứ nhất nhận một chuỗi chứa tên của nhóm cần kiểm tra. Tên nhóm phải
có dạng [DomainName]\[GroupName] đối với các nhóm dựa-trên-miền và phải có
dạng [MachineName]\[GroupName] đối với các nhóm được định nghĩa cục bộ. Nếu
muốn kiểm tra tư cách thành viên của một nhóm Windows chuẩn, bạn hãy sử dụng
dạng BUILTIN\[GroupName]. IsInRole thực hiện kiểm tra có phân biệt chữ hoa-
thường đối với tên nhóm được chỉ định.
• Phiên bản thứ hai nhận một số nguyên (int), số này chỉ định một Windows Role
Identifier (RID). RID cung cấp một cơ chế để nhận biết các nhóm, không phụ thuộc
vào ngôn ngữ (language) và sự bản địa hóa (localization).
• Phiên bản thứ ba nhận một thành viên thuộc kiểu liệt kê
System.Security.Principal.WindowsBuiltInRole. Kiểu liệt kê này định nghĩa các
thành viên mô tả các nhóm Windows có sẵn. Bảng 13.3 liệt kê tên, RID, và giá trị
WindowsBuiltInRole cho mỗi nhóm Windows chuẩn.
Bảng 13.3 Tên, RID, và giá trị WindowsBuiltInRole của các tài khoản có sẵn
Giá trị
Tên tài khoản RID (Hex)
WindowsBuiltInRole
BUILTIN\Account
0x224 AccountOperator
Operators
BUILTIN\Administrators 0x220 Administrator
BUILTIN\Backup Operators 0x227 BackupOperator
BUILTIN\Guests 0x222 Guest
BUILTIN\Power Users 0x223 PowerUser
BUILTIN\Print Operators 0x226 PrintOperator
BUILTIN\Replicators 0x228 Replicator
BUILTIN\Server Operators 0x225 SystemOperator
BUILTIN\Users 0x221 User
[
- Lớp WindowsIdentity cung cấp các phương thức khởi dựng nạp chồng cho
phép bạn thu lấy đối tượng WindowsIdentity mô tả một người dùng nào đó
(khi chạy trên Microsoft Windows Server 2003 trở về sau). Bạn có thể sử dụng
đối tượng này và phương pháp được mô tả trong mục này để xác định xem
người dùng đó có phải là thành viên của một nhóm Windows nào đó hay không.
Nếu bạn sử dụng một trong các phương thức khởi dựng này khi chạy trên một
phiên bản Windows cũ, nó sẽ ném ngoại lệ System.ArgumentException. Trên các
nền Windows trước Windows Server 2003, bạn phải sử dụng mã lệnh nguyên
sinh (native code) để thu lấy Windows access token mô tả người dùng cần thiết.
Kế đó, bạn có thể sử dụng access token này để tạo đối tượng WindowsIdentity;
mục 13.15 sẽ trình bày cách thu lấy Windows access token cho những người
dùng cụ thể.
Ứng dụng WindowsGroupExample dưới đây trình bày cách kiểm tra người dùng hiện
hành có là thành viên của một tập các nhóm Windows được nêu tên hay không. Các nhóm
này được chỉ định trong các đối số dòng lệnh; bạn nhớ đặt tên máy tính, tên miền, hay
BUILTIN (đối với các nhóm Windows chuẩn) vào trước tên nhóm.
using System;
using System.Security.Principal;
public class WindowsGroupExample {
public static void Main (string[] args) {
// Thu lấy đối tượng WindowsIdentity
// mô tả người dùng hiện hành.
WindowsIdentity identity = WindowsIdentity.GetCurrent();
// Tạo đối tượng WindowsPrincipal mô tả các khả năng bảo mật
// của đối tượng WindowsIdentity được chỉ định.
WindowsPrincipal principal = new WindowsPrincipal(identity);
// Duyệt qua các đối số dòng lệnh (tên nhóm) và kiểm tra xem
// người dùng hiện hành có là thành viên của mỗi nhóm hay không.
foreach (string role in args) {
Console.WriteLine("Is {0} a member of {1}? = {2}",
identity.Name, role, principal.IsInRole(role));
}
- }
}
Nếu bạn chạy ví dụ này với tư cách người dùng có tên là nnbphuong81 trên một máy tính
có tên là MACHINE bằng lệnh WindowsGroupExample BUILTIN\Administrators
BUILTIN\Users MACHINE\Accountants, kết xuất có thể như sau:
Is MACHINE\nnbphuong81 a member of BUILTIN\Administrators? = False
Is MACHINE\nnbphuong81 a member of BUILTIN\Users? = True
Is MACHINE\nnbphuong81 a member of MACHINE\Accountants? = True
nguon tai.lieu . vn
