CLR 4.0 transparent security
CLR 4.0 transparent security
CLR 4.0 come with some changes to the security model.
in general the CLR 4.0 no longer assume the sandbox for the application.
you can still sandboxed your AppDomain and the CLR 4.0 will onerous that sandbox,
but running the same exe from local computer or from network shared folder
won't grant the exe different privileges (sandbox).
as result the security setting goes back into the administrators hands,
as it was before the .NET era and application restriction will be define equally
for both manage and unmanaged code.
the security is back again done at the OS level.
what you should be aware of the the transparent code concept,
and that security is no longer can be define at the assembly level (all the definition should done at the AppDomain level).
Transparent code concept
the analysis of .NET fundamental operation observe that there are only 2 operation which are dangerous:
- unverifiable code
- calling unmanaged code (P-Invoke / COM)
potentially harm operations define as security critical, and cannot be invoke directly from security non critical (transparent) code.
if non security critical (transparent) code need access for security critical operation,
it should do so by calling security safe critical operation (which play the role of the man in the middle).
this exactly what happens when you need to persist data into file
using in-browser Silverlight application,
the file open define as security critical so you have no direct access to this operation,
and the isolated storage defined as security safe critical, so it give you indirect
access to the security critical file open but only to restricted file paths.
Code snippet
you can get the code snippet from here.
Code Snippet
- [assembly: AllowPartiallyTrustedCallers]
- [assembly: SecurityRules(SecurityRuleSet.Level2)]
- namespace TransparentSecurity
- {
- class Program
- {
- static void Main(string[] args)
- {
- var criticalFoo = new CriticalFoo();
- try
- {
- criticalFoo.DoDangerousOperation(AppDomain.CurrentDomain.BaseDirectory);
- }
- catch (Exception ex) { Console.WriteLine(ex.Message); }
-
- try
- {
- criticalFoo.DoSafeOperation(AppDomain.CurrentDomain.BaseDirectory);
- }
- catch (Exception ex) { Console.WriteLine(ex.Message); }
- }
- }
-
- public class CriticalFoo
- {
- [SecuritySafeCritical]
- public void DoSafeOperation (string path)
- {
- var prm = new FileIOPermission(FileIOPermissionAccess.AllAccess, path);
- prm.Demand();
- DoDangerousOperation(path);
- }
-
- [SecurityCritical]
- public void DoDangerousOperation (string path)
- {
- Console.WriteLine(path);
- }
- }
- }
line 1: by default your code consider security critical unless you decorate it with [AllowPartiallyTrustedCallers] attribute.
line 2: setting the security rules to level 2, is the default CLR 4.0 security model (level 1 is CLR 2 backward compatibility).
line 34: decorate the method as security critical (therefore it can be assessed only by security critical or security safe critical operations).
line 12: this invocation won't succeed because security non critical (transparent) operations cannot access security critical operations.
line 26: decorate the method as security safe critical (so this code can target security critical operation and be target by
security non critical code).
lines 29,30: restrict the access using demand for file permission to the specific folder.
Summary
CLR 4.0 security model is taking one step back from absolute security management,
and one step to the to the side and forward by giving us more simple and understandable security model.
the transparent model dose not restrict malicious code from accessing critical operation,
(because the malicious code can be decorate with security safe critical), what it does is helping the
CLR to put it's security focus on the dangerous code section.
Point of interest
you can learn more about the CLR 4.0 security concepts on this video by Shawn Farkas.
תגים של Technorati:
security,
clr 4,
.nrt
