Code Access Security
CS 795
Chapters 5-9 (O’Reilly Book)
Chapter 13 (Barry Dorrans)
References
Videos:
– http://www.youtube.com/watch?v=qNnOi5xi9KM
– http://www.codeproject.com/Articles/120911/CAS-Code-access-security-NETSecurity-model-FA
– http://www.youtube.com/watch?v=RitDp3pDYK8
• Slides:
– http://slideplayer.us/slide/276700/#.U814cEbkFdM.gmail
• Explanation:
– http://msdn.microsoft.com/en-us/library/ff648663.aspx
Terminology-SPC
• Software Publisher Certificate (SPC): Provide
identity of the assembly publisher
• Signcode scheme---using this a digital signature
is created using the private key components of
the certificate and is embedded into the
assembly along with the public key component
of the SPC
•
•
•
creates a certificate with a public key
and stores it in TestCert.cer; corresponding private key is stored in
MyPrivateKey.pvk
Cert2spc TestCert.cer TestSPC.spc
Signcode –spc TestSPC.spc –v MyPrivateKey.pvk SingleFileAssembly.dll
Makecert –sv MyPrivateKey.pvk TestCert.cer
Terminology-GAC
• GAC: Global Assembly Cache
• If an assembly is shared by several applications, it can
be installed into the GAC.
• It is a machine-wide store of shared assemblies
• Why place it in GAC?
– .Net framework automatically looks for an assembly in GAC; so
no need to configure to find it
– File security---tamper proof
– Simplify administration
– Multiple versions may exist
– gacutil /i SingleFileAssembly.dll ---install a file into GAC
– gacutil /l – lists contents of GAC
– gacutil /l SingleFileAssembly ---lists the attributes of this file
– gacutil /u SingleFileAssembly ---to uninstall
Terminology—Application Domain
• Logical containers within CLR that provide an isolation boundary for
an application
• Similar to protection provided by processes in a Unix environment--no sharing of address space, etc.
• It is possible for a single process to run multiple applications without
any boundary violations
• Assemblies within an application may be isolated from each other
Process
CLR
App Domain 1
Assembly1 Assembly2
App Domain 2
Assembly3
More on Application Domains and Security
• Assembly evidence and identity—when an assembly is loaded into
an app domain, we can specify additional evidence to apply to the
assembly---evidence determines the permissions granted by CLR to
the assembly
• Application domain evidence and identity--when an application
domain is created, it can be assigned some evidence; CLR grants
permissions to an app domain based on the evidence; an action by
an assembly is controlled both by assembly permission set and app
domain permission set.
• App domains and security policy---while the enterprise level,
machine level, and user level security policy levels are fixed, app
domain security policy may be defined programmatically
• App domains and role-based security: By default, the app domain
through which a thread runs, defines the principal on whose behalf
the thread acts.
• App domain and isolated storage: This is based on the identity of the
assembly and the app domain in which the assembly is loaded.
http://ondotnet.com/pub/a/dotnet/2003/04/21/isolatedstorage.html
Code Access Security (CAS)
• A means to assign identity or evidence to
.Net assemblies
• User identities are not in this picture; only
assembly identities
• Code that is running may be denied
access to a resource
• Suitable for environments where partially
trusted code runs
CAS (cont.)
• .Net Framework uses CAS to provide an optional sandbox for
managed code.
• It is used to limit access that programs have to protected resources
and operations---regardless of the user running the program.
– For example, with a non-CASA program such as Notepad, an
Admin could write a textfile to C:\Window because his/her
account has permission to do so. No restrictions are placed on
the Notepad program.
– A CAS-enabled editor, however, could have restrictions set up
on it---for example, it may not be allowed to write to C:\Windows.
So even though Admin has a right to write on C:\Windows,
his/her attempt to write using the editor would fail to write here.
CAS (cont.)
• Authentication: Deals with assembly evidence
(and not Windows principals)
• Authorization: Not related to OS-level objects;
instead they concern with standard application
tasks such as accessing a database via an
OLEDB provider or a resource on the Internet
via a URL
• CAS permissions are directly attached to
assemblies at load time
Application Trust Levels
•
•
•
Full Trust: No restrictions imposed by code access security.
High Trust:
– No unmanaged code.
– Can access Microsoft SQL Server and other OLE DB data sources.
– Can send e-mail by using SMTP servers.
– Very limited reflection permissions. No ability to invoke code by using reflection.
– A broad set of other framework features are available. Applications have full
access to the file system and to sockets.
Medium Trust:
– Permissions are limited to what the application can access within the directory
structure of the application
– No file access is permitted outside of the application's virtual directory hierarchy.
– Can access SQL Server.
– Can send e-mail by using SMTP servers.
– Limited rights to certain common environment variables.
– No reflection permissions whatsoever.
– No sockets permission.
– To access Web resources, you must explicitly add endpoint URLs —
either in the
originUrl attribute of the <trust> element or inside the policy file.
Application Trust Levels (cont.)
• Low Trust:
– Intended to model the concept of a read-only application with no
network connectivity.
– Read only access for file I/O within the application's virtual
directory structure.
• Minimal Trust:
– Execute only.
– No ability to change the IPrincipal on a thread or on the
HttpContext.
If an application calls unmanaged code, it must run with Full trust.
Even the least restrictive partial trust level, High, does not permit
calls to unmanaged code.
Application Trust Levels (cont.)
• To choose an appropriate trust level
(http://msdn.microsoft.com/en-us/library/ff649312.aspx)
– Examine each trust level, beginning with High trust.
– Look inside the High trust policy file, web_HighTrust.config.
– If your application requires fewer code access security
permissions than those provided by the High trust level, move on
to consider Medium trust.
– Repeat the process, moving from Medium to Low to Minimal,
and keep evaluating the partial trust levels until you reach an
exact match to your application's requirements or until your
application's required permissions slightly exceed a partial trust
level.
– This process will help you to identify a trust level that matches
your application's code access security permission requirements
as closely as possible but does not grant permissions that your
application does not need.
Application Trust Levels (cont.)
Configuring Your ASP.NET Application
The following example shows how to configure your application for
Medium trust.
...
<system.web>
...
<trust level="Medium" originUrl="" />
...
</system.web>
...
CAS Evidences for an Assembly
• Assembly inner (fixed) properties (e.g.,
assembly Strong Name or Publisher) and
assembly origin (variable) information (e.g.,
URL, Site, Zone)
• .Net Built-in evidences (automatically evaluated
and attached to the assembly by the CLR loader
when referenced the 1st time):
Application Directory
Hash (Cryptographic hash)
Publisher (Authenticode signature)
Site (Site of origin: http://www..)
Strong name (cryptographically strong)
URL (URL of origin)
Zone (Zone of origin such as internet zone)
Assembly origin
Within assembly
Within assembly
Assembly origin
Within assembly
Assembly origin
Assembly origin
Application Domain and Assembly Evidence
• CLR exposes methods to enable users to create application
domains or load assemblies explicitly. At this time it allows us to
modify the evidence set (add new evidence or override evidence
provided by CLR)
• Nothing can be done when it is loaded automatically by the CLR
• BCL – base class library
• Creating a new evidence set object:
Evidence ev = AppDomain.CurrentDomain.Evidence;
Zone z = new Zone(SecurityZone.Internet);
ev.AddHost(z);
AppDomain myappdomain =
AppDomain.CreateDomain(“myappdomain”, ev);
For an assembly, CLR provides evidence but we can override it:
Zone z = new Zone(SecurityZone.Internet);
ev.AddHost(z);
Myappdomain.ExecuteAssembly(http://localhost/cas/ConsoleApplic
ation1.exe, ev);
CAS Permissions
• .Net BCL comes with a list of built-in
permission classes, one for each resource
or service it provides access to:
•
•
•
•
•
•
•
•
System.DirectoryServices.DirectoryServicesPermission
System.NET.DnsPermissions
System.EnvironmentPermission
System.Diagnostics.EventLogPermission
System.Security.SecurityPermissions
System.Data.OledbPermission
Many more
SystemPermissions class is used to allow permission to different disparate
actions such as assembly evidences, creating application domains, and
calling into unmanaged code
CAS Permissions (cont.)
Resources Accessed
Required Permissions
DNS directory
DnsPermission
Environment variables
EnvironmentPermission
Event log
EventLogPermission
File dialog
FileDialogPermission
File system
FileIOPermission
Isolated file storage
IsolatedStoragePermission
Key containers
KeyContainerPermission
Message queues
MessageQueuePermission
Network information and traffic
statistics
NetworkInformationPermission
OLE DB data sources
OleDbPermission
Performance counters
PerformanceCounterPermission
Printers
PrintingPermission
CAS Permissions (cont.)
Resources Accessed
Required Permissions
Reflection
ReflectionPermission
Registry
RegistryPermission
Security
SecurityPermission
SMTP servers
SmtpPermission
Sockets
SocketsPermission
SQL Server notifications
SqlNotificationPermission
SQL Server
SqlClientPermission
Stores containing X.509 certificates
StorePermission
User interfaces and clipboard
UIPermission
Web services (and other HTTP Internet
WebPermission
resources)
CAS Policies
• Assembly binding behavior can be configured at different levels
based on three XML files:
– Application configuration file.
– Publisher policy file.
– Machine configuration file.
• It is also possible to define an application-specific policy and inject it
into a newly created application domain
• Final permissions are granted by the CAS to an assembly will be
those granted in the intersection of the permissions
CAS Policies (cont.)
http://www.icodeguru.com/dotnet/core.c.sharp.and.dot.net/0131472
275/ch15lev1sec3.html
Permission Sets and Code Groups
•
•
•
•
•
•
•
•
Permission Set: named set of permissions registered in a specific security
policy.
Membership condition: A specific value of an evidence type; e.g.,
Zone=Internet; URL=http://…..
Code Groups: Building blocks of security policies. It is an association
between a membership condition and a permission set.
When an assembly evidence contains an evidence entry matching the code
group membership condition, that assembly is a member of the code group,
and thus permission set assigned to the code group is granted to the
assembly
Example classes: UnionCodeGroup, NetCodeGroup, FileCodeGroup
Example: Suppose a Code Group B has the membership condition:
Zone=Intranet and Permission Set = Everything. Suppose an assembly A
has the following evidence set: Zone = X, Hash = Y, Strong Name = Z. So if
X = Intranet, then Assembly A will be granted the Permission set of
Everything.
Built-in Permission Sets: FullTrust, SkipVerification, Execution, Nothing,
LocalIntranet, Internet, Everything
By Default, FullTrust and Everthing or identical permission sets. However,
FullTrust may have additional custom permissions, if defined.
Policy Structure Object: Model
• Enables us to:
–
–
–
–
–
Navigate along the code group structure, and modify it
Get and Set a group’s membership conditions and permission set
Resolve membership conditions against an assembly evidence, and
So on
RootCodeGroup property of a PolicyLevel object provides access to the
root code group object of the policy. From that, we can get an
enumerator to access its child group using Children property, and so on.
Ex:
IEnumerator policyenumerator = SecurityManager.PolicyHierarchy();
While (policyenumerator.MoveNext())
{ PolicyLevel aPolicyLevel = (PolicyLevel) Policyenumerator.Current;
CodeGroup rootcodegroup = aPolicyLevel.RootCodeGroup;
Debug.WriteLine(rootcodegroup.name)
}
Policy Evaluation
• Complex due to the hierarchical nature of
code groups in a CAS policy
• The order of execution: Enterprise,
Machine, and User, and app domain.
• Result is permissions granted to an
assembly by intersecting permissions
granted by each policy
CAS and ASP.Net Applications
• In the most common scenario: ASP.Net applications are
deployed in IIS virtual directory; thus according to CAS,
Zone=MyComputer evidence value. Thus, FullTrust
permission set is granted to ASP.Net assemblies (as a
default)
• Exception 1: Within an ASP.Net page, an assembly is
downloaded from a URL ; CAS assigns limited
permissions; developers will have to modify security
policy config to provide additional permissions if needed.
• Exception 2: IIS Virtual directory is mapped to a UNC
(Universal naming convention like \\Potato\Chips or
//servername/path) path. Here, ASP.Net assemblies are
loaded with intranet permission set; they may not be
sufficient to run an assembly
CAS Limitations
• CAS can perform access control only on managed code
– For security reasons, do not allow calls to unmanaged
assemblies
– Do not load .Net applications that we do not trust from
Zone=MyComputer
• As long as Windows allows unmanaged code to run,
nothing will prevent a virus from modifying security
policies (XML files) --- To set a permission set from
Nothing to FullTrust.
• For CAS to be secure, a robust ACL permission policy is
essential.
Security Requests
• This takes place during the last stage of the assembly
load time phase
• By placing security requests on assembly metadata, we
can notify CAS about some permissions that we wish to
associate with the assembly:
– Request minimum (if these are not there), don’t load;
– Optional needs (needed but don’t abort loading if
they are absent);
– Refuse permissions—don’t give these
• By default, optional permissions are all permissions.
Thus, by specifying optional, we are reducing the scope.
• By placing the requirements in metadata, they can be
viewed with the permission tool (Permview.exe) and can
adjust security policies
Security Requests (cont.)
[assembly:
FileIOPermission(SecurityAction.RequestMinimum,
All=“c:\temp”)]
[assembly:
SqlClientPermission(SecurityAction.RequestMinimum,
Unrestricted=true)]
Result: Granted permissions = (policies granted
permissions) intersect (requested minimum union
requested optional)-(refused permission)
Alternately, built-in types:
[assembly:
PermissionSet(SecurityAction.RequestMinimum,
Name=“FullTrust”);
(or Internet, LocalIntranet, SkipVerification)
Run-time Security Demands
•
•
•
Demand, Assert, Deny, PermitOnly
Declaratively (via attributes) or imperatively by programmatic settings.
Demand---Request CLR to perform the stack walk process
[FileIOPermission(SecurityAction.Demand, Read=“c:\\”]
Public class Class1
{ public void dowork()
{
SocketPermission sockperm = new
SocketPermission(NetworkAccess.Connect,TransportType.Tcp,www.cs.odu.edu);
sockperm.Addpermission
(SocketPermission(NetworkAccess.Connect,TransportType.Tcp,www.cs.virginia.edu)
;
sockperm.Demand();
}
}
More on Demand()
• If an assembly demands a permission it has not
been granted, no exception is thrown!!
• When a declarative demand fails, an exception
is thrown to the direct caller
• When an imperative demand fails, an exception
is thrown within the method call demanding the
permission
• When a Demand call is encountered at run time,
CLR picks up the demanded permission object
and performs a stack walk along the assembly
call chain.
Stack Walk
•
•
To determine whether code is authorized to access a resource or perform an
operation, the runtime's security system walks the call stack, comparing the granted
permissions of each caller to the permission being demanded. If any caller in the call
stack does not have the demanded permission, a security exception is thrown and
access is refused. The stack walk is designed to help prevent luring attacks, in which
less-trusted code calls highly trusted code and uses it to perform unauthorized
actions. Demanding permissions of all callers at run time affects performance, but it is
essential to help protect code from luring attacks by less-trusted code. To optimize
performance, you can have your code perform fewer stack walks; however, you must
be sure that you do not expose a security weakness whenever you do this.
The following illustration shows the stack walk that results when a method in
Assembly A4 demands that its callers have permission P.
•
•
•
•
•
•
Assert
RevertAssert
Deny
RevertDeny
PermitOnly
RevertPermitOnly
Modify stack walk--Assert()
•
•
To stop stack walking and force a positive outcome of the Demand call.
It is a method that can be called on code access permission classes and on the
PermissionSet class.
• It enables your code (and downstream callers) to perform actions that your code has
permission to do but its callers might not have permission to do. A security assertion
changes the normal process that the runtime performs during a security check. When
you assert a permission, it tells the security system not to check the callers of your
code for the asserted permission.
• Ex: An assembly accesses the windows registry via Microsoft.Win32.Registry class,
which raises security demands at runtime. The assembly may not require all callers
to have this ability.
Declaratively:
[PermissionSet (SecurityAction.Assert, Name= “FullTrust”)]
Imperatively:
Public void dowork()
{ FileIOPermission x = new FileIOPermission (FileIOPermissionAccess.Read, “c:\\”);
x.Assert();
}
Example
http://msdn.microsoft.com/enus/library/vstudio/91wteedy(v=vs.100).aspx
• P1A represents the right to read .txt files on the C drive.
• P1 represents the right to read all files on the C drive.
• P1A and P1 are both FileIOPermission types, and P1A is a subset
of P1.
• Assemblies E and F have been granted P1A permission.
• Assembly C has been granted P1 permission.
• Assemblies A and B have been granted neither P1 nor P1A
permissions.
• Method A is contained in assembly A, method B is contained in
assembly B, and so on.
Example (cont.)
•
•
•
•
•
Here, method A calls B, B calls C, C calls E, and E calls F.
C asserts permission to read files on the C drive (permission P1)
Method E demands permission to read .txt files on the C drive (permission
P1A).
When the demand in F is encountered at run time, a stack walk is performed to
check the permissions of all callers of F, starting with E. E has been granted
P1A permission, so the stack walk proceeds to examine the permissions of C,
where C's assertion is discovered.
Because the demanded permission (P1A) is a subset of the asserted
permission (P1), the stack walk stops and the security check automatically
succeeds. It does not matter that assemblies A and B have not been granted
permission P1A. By asserting P1, method C ensures that its callers can access
the resource protected by P1, even if the callers have not been granted
permission to access that resource.
Modify Stack Walk – Deny()
• Deny has the opposite effect of Assert
•
http://msdn.microsoft.com/en-us/library/hk3b9142.aspx
• It is used in situations where we want to
prematurely stop a stack walk, and force a
negative outcome.
• Of course, the assembly calling Demand must
be granted the demanded permission being
checked by the stack walk.
• Example (at class level): Denying permission to
call an unmanaged code
[SecurityPermission(SecurityAction.Deny, UnmanagedCode=false)]
Public class Form1: …
Example
((http://diranieh.com/NETSecurity/Writing%20Secure%20Cl
ass%20Libraries.htm
•P1 represents the right to read all files on the C drive.
•All five assemblies have been granted permission P1.
•Method F in assembly F demands permission P1.
•Method C in assembly C calls Deny on Permission P1:
Modify Stack--PermitOnly
•
It is similar to Deny in the sense both cause stack walks to fail when they
would otherwise succeed.
•
http://msdn.microsoft.com/en-us/library/system.security.codeaccesspermission.permitonly(VS.80).aspx
•
It is different from Deny --- Deny specifies permissions that will cause the
stack walk to fail, but PermitOnly specifies the only permissions that do not
cause the stack walk to fail.
Here, we have to specify what permissions will not determine a negative
outcome (or continue stack walk unaffected).
•
public MethodB() {
try{
FileIOPermission p = new FileIOPermission(PermissionState.Unrestricted);
P.PermitOnly();
} catch (SecurityException se) { // Handle exception}
}
Here, MethodB will cause a stack walk to terminate if methods further down the call stack
demand any permissions other than a FileIOPermission.
PermitOnly is ignored for a permission not granted because a demand for that permission will not succeed.
However, if code lower on the call stack later calls Demand for that permission, a SecurityException is
thrown when the stack walk reaches the code that tried to call PermitOnly. This is because the code that
called PermitOnly has not been granted the permission, even though it called PermitOnly for that
permission. The call stack is typically represented as growing down, so that methods higher in the call stack
call methods lower in the call stack.
References
• http://www.codeproject.com/dotnet/UB_CAS_NET.asp
•
http://www.codeguru.com/columns/DotNet/article.php/c9253/
• http://www.codeguru.com/columns/dotnet/article.php/c9393/
• http://www.developer.com/security/article.php/3483866
•
http://msdn2.microsoft.com/en-us/library/87x8e4d1.aspx
•
http://www.code-magazine.com/Article.aspx?quickid=0405031
•
www.theserverside.net/articles/ content/PracticalDotNet2/PracticalDotNet2Ch6.pdf
•
geekswithblogs.net/claeyskurt/Rss.aspx
What about .Net 4?
• With all the changes in the security system of .NET 4, the question
frequently arises “so, is CAS dead now?”.
• One of the reasons that this question comes up so frequently, is that
the term CAS in the .NET 1 security model was overloaded to refer
to many different aspects of the security system:
– CAS policy – policy levels, code groups, and of course our old friend
caspol.exe
– CAS enforcement – primarily the act of demanding and asserting
permissions
– CAS permissions – granted by CAS policy or a host to set the level of
operations that an application can perform
Problems with CAS
There are many problems with CAS policy.
– There are versioning problems.
– The host doesn’t have control over the policy applied
to the code it is hosting.
– Enterprise administrators don’t have a good way to
deploy CAS policy updates.
– CAS policy caused managed applications to run
differently from native applications, often in confusing
and undesirable ways.
– And of course, there’s the general complexity and
difficulty of use.
Remedy
•
•
•
•
For these reasons, in v4 of the CLR, CAS policy has been deprecated and
policy decisions are instead left entirely up to the host of an application.
However, the other security mechanisms that fell under the name CAS,
which allow hosts to configure AppDomains to host sandboxed code and
allow library authors to write a safe library exposing services to partial trust
absolutely still exist and are supported.
For instance, when a host sets up a sandboxed AppDomain to run code in,
it does this by figuring out what grant set should be given to an application
and supplying that grant as a set of permissions – the exact same
permissions that have been used since v1 of the .NET Framework. Custom
permissions can still be created by hosts or library authors to protect their
libraries, and assemblies and AppDomains still receive permission objects
in their grant sets.
Similarly, permissions demands are still alive and well, and are one of the
most common ways that safe critical APIs in will check to ensure that the
sandbox they are running in supports a given operation. For example,
opening a file is a security safe critical operation which demands
FileIOPermission to ensure that the host has setup the current sandbox with
permission to access the requested file.
• Even though we’ve moved away from CAS policy, the CLR still
provides mechanisms for partially trusted code to be setup and run.
• A lot of our work with security transparency was to make it safer for
library authors to expose their code to partial trust.
• The new SecAnnotate tool was designed exactly to help ensure that
more libraries could be safely exposed in a partial trust sandbox.
Security Transparent Code
•
•
•
•
Security policy was a key element in previous versions of the .NET Framework.
Starting with the .NET Framework 4, security policy is obsolete. The elimination of
security policy is separate from security transparency.
Transparency is an enforcement mechanism that separates code that runs as part of
the application from code that runs as part of the infrastructure.
– Transparency draws a barrier between code that can do privileged things (critical
code), such as calling native code, and code that cannot (transparent code).
Transparent code can execute commands within the bounds of the permission
set it is operating in, but cannot execute, derive from, or contain critical code.
– The primary goal of transparency enforcement is to provide a simple, effective
mechanism for isolating different groups of code based on privilege. Within the
context of the sandboxing model, these privilege groups are either fully trusted
(that is, not restricted) or partially trusted (that is, restricted to the permission set
granted to the sandbox).
Transparency is enforced by the just-in-time compiler and remains in effect
regardless of the grant set for an assembly, including full trust.
Transparency was introduced in the .NET Framework version 2.0 to simplify
the security model, and to make it easier to write and deploy secure libraries
and applications.
Security Transparent Code (cont.)
• Specifying the Transparency level: The assembly-level
SecurityRulesAttribute attribute explicitly selects the
SecurityRuleSet rules that the assembly will follow. The rules are
organized under a numeric level system, where higher levels mean
tighter enforcement of security rules.
• The levels are as follows:
– Level 2 (Level2) – the .NET Framework 4 transparency rules.
– Level 1 (Level1) – the .NET Framework 2.0 transparency rules.
– The primary difference between the two transparency levels is
that level 1 does not enforce transparency rules for calls from
outside the assembly and is intended only for compatibility.
Level 2 Transparency
•
•
Level 2 transparency was introduced in the .NET Framework 4. The three tenets of
this model are transparent code, security-safe-critical code, and security-critical code.
Transparent code, regardless of the permissions it is granted (including full trust), can
call only other transparent code or security-safe-critical code. If the code is partially
trusted, it can only perform actions that are allowed by the domain’s permission set.
Transparent code cannot do the following:
– Perform an Assert operation or elevation of privilege.
– Contain unsafe or unverifiable code.
– Directly call critical code.
– Call native code or code that has the SuppressUnmanagedCodeSecurityAttribute
attribute.
– Call a member that is protected by a LinkDemand.
– Inherit from critical types.
–
•
•
In addition, transparent methods cannot override critical virtual methods or implement critical interface
methods.
Security-safe-critical code is fully trusted but is callable by transparent code. It
exposes a limited surface area of full-trust code. Correctness and security
verifications happen in safe-critical code.
Security-critical code can call any code and is fully trusted, but it cannot be called by
transparent code.
Level 1 Transparency
•
•
•
The level 1 transparency model was introduced in the .NET Framework version 2.0 to enable
developers to reduce the amount of code that is subject to a security audit. Code that is identified
as transparent does not require a high degree of security auditing.
Level 1 transparency states that the transparency enforcement is limited to within the assembly. In
other words, any public types or members that are identified as security-critical are security-critical
only within the assembly. If you want to enforce security for those types and members when they
are called from outside the assembly, you must use link demands for full trust. If you do not,
publicly visible security-critical types and members are treated as security-safe-critical and can be
called by partially trusted code outside the assembly.
The level 1 transparency model has the following limitations:
– Security-critical types and members that are public are accessible from securitytransparent code.
– The transparency annotations are enforced only within an assembly.
– Security-critical types and members must use link demands to enforce security
for calls from outside the assembly.
– Inheritance rules are not enforced.
– The potential exists for transparent code to do harmful things when run in full
trust.
Enforcing Transparency
• Transparency rules are not enforced until transparency is calculated.
At that time, an InvalidOperationException is thrown if a
transparency rule is violated.
• The time that transparency is calculated depends on multiple factors
and cannot be predicted. It is calculated as late as possible. In the
.NET Framework 4, assembly-level transparency calculation occurs
sooner than it does in the .NET Framework 2.0.
• The only guarantee is that transparency calculation will occur by the
time it is needed. This is similar to how the just-in-time (JIT) compiler
can change the point when a method is compiled and any errors in
that method are detected.
• Transparency calculation is invisible if your code does not have any
transparency errors.
What are the changes in .NET 4.0 security model &
What is sandboxing?
•
•
•
CAS is completely deprecated in .NET 4.0 and there are 2 big changes done in .Net
4.01. Granting of permission is dependent on the host and not the CAS Model.
2. Introduction of Security Transparent Model. In this .NET Code is divided in 3 kinds
of code– I. Security Critical Code – A full trusted code if known as Security Critical Code
and it has full access to my system. We need to ensure that this code is not
called by unsafe code (Security Transparent Code).To create a code as Security
Critical we have to put “[assembly: SecurityCritical()]” attribute in
Properties->Assemblyinfo.cs
– II. Security Transparent Code – A code which you feel unsafe is known as
Security Transparent Code. To create a code as Security Critical we have to put
“[assembly: SecurityTransparent()]” attribute in Properties->Assemblyinfo.cs
– III Security Safe Critical Code- A Bridge between Security Transparent Code and
Security Critical Code to access Security Critical Code via Security Transparent
Code.
• Security Transparent model is good if the code control is in our
hand.
• Sandboxing- If you want to execute an untrusted third party DLL you
can create your own “Appdomain” and assign permission set so that
your third party DLL runs under a control environment. This process
is called sandboxing.
• To implement Sandboxing first we have to create the object of
“PermissionSet” and assign Permissions as per our requirement,
then we have to create “AppDomain” object with the permissionset
object we created and in this “AppDomain” object we will put that
class in which we want to implement Sandboxing.
•
http://www.codeproject.com/Articles/782803/What-are-the-Changes-in-NET-SecurityModel-What-is