dotnet security: enumerate runtime permissions -- dotnet security

Re: enumerate runtime permissions

Jas
9/26/2005 12:10:04 PM

In the process of learning how application domains work within .NET CLR I was
writing test code which instantiated a new application domain with manually
specificed evidence set during runtime. And, I loaded an assembly into this
new application domain and wanted for it to print out its grant set,
literally every permission granted to it. I could use imperative syntax to
assert permissions in try catch block, but I was wondering if there is a more
elegant way to do this with support from the runtime.

[quoted text, click to view]

Re: enumerate runtime permissions

Nicole Calinoiu
9/27/2005 8:34:51 AM

[quoted text, click to view]

In that case, you could definitely call into a fully trusted assembly to get
the grant set. The easiest approach to determining a caller's permissions
in this sort of scenario is to demand full trust, then read the actual grant
set from the SecurityException that will result if the caller is not fully
trusted. To do this, add the following method in an assembly that will be
fully trusted, then call it from within the assembly whose permissions you
wish to test:

public string ReadPermissionGrant()
{
PermissionSet fullTrust = new
PermissionSet(PermissionState.Unrestricted);
string grantedSet = null;

try
{
fullTrust.Demand();
grantedSet = fullTrust.ToString();
}
catch (SecurityException ex)
{
fullTrust.Assert();
try
{
grantedSet = ex.GrantedSet;
}
finally
{
CodeAccessPermission.RevertAll();
}
}

return grantedSet;
}

While the above will work for your exploratory scenario, it is not suitable
for production use for at least a few reasons:

1. The demand may fail due to any assembly on the call stack, so it's only
suitable for use when you can control the call stack being tested.
2. The demand may be affected by call stack modifiers, so it's only
suitable for use when you can ensure that none have been applied.
3. Since the method may return the permission grant of an assembly other
than the direct caller's, the assertion of permissions required to read that
grant may open up new security holes, so the method shouldn't be used in a
production application unless additional protections are added to prevent
potential misuse of the method.

[quoted text, click to view]

Assertions won't help you figure out what permissions were granted. They'll
only help you run code despite the fact that caller(s) don't possess the
permission(s) being asserted.

[quoted text, click to view]

Re: enumerate runtime permissions

Jas
9/27/2005 7:55:04 PM

Nicole,

That's a creative way to figure out my permissions! I'll try it out.

Additionally, when I mentioned using asserts in try catch blocks, I was
going to try to assert all permissions, and obviously the runtime would not
let me assert permissions I don't have, so I could figure out by trial and
error which permissions I do and don't have based on which asserts pass and
which fail.

[quoted text, click to view]

Re: enumerate runtime permissions

Nicole Calinoiu
10/9/2005 9:23:12 AM

[quoted text, click to view]

Only in the sense that the assertion would have no effect, but not in the
sense that an exception would be thrown when your code performs the
assertion. The attempt to assert a permission that an assembly does not
possess fails only when the permission is eventually demanded, not when it
is initially asserted. The observed behaviour is exactly as if the
assertion was never made (i.e.: demand fails as if no stack walk modifier
were applied).

[quoted text, click to view]

Got something to say? Click here to post a reply to this thread.

Don't see what you're looking for? Try a search.

View other messages in the dotnet security group.