enumerate runtime permissions

microsoft.public.dotnet.security

26 Sep 2005 2:46 AM

Jas

Is there a way for an assembly to enumerate all the permissions granted to it
by the runtime? For some reason I remember reading somewhere in the past
that you can't do this, but I wasn't sure.

26 Sep 2005 12:21 PM

Nicole Calinoiu

Yes and no. There are ways to read the permission grant, but they all
require at least one "dangerous" permission, so they tend to be somewhat
useless for reading the permission grant of a limited-permission assembly
from within the target assembly itself. However, if you can somehow involve
a highly privileged assembly in the process, one of these may work for you.

There are also some other options for detecting whether a specific
permission (or set of permissions) has been granted to a given assembly
which, depending on what you're trying to do, may be a better approach.
So... In what scenario do you need this information, and what would you do
with it once you've got it?

Show quoteHide quote

"Jas" <J**@discussions.microsoft.com> wrote in message
news:EBFBFC19-E96C-439B-BCB9-59E41FD21514@microsoft.com...
> Is there a way for an assembly to enumerate all the permissions granted to
> it
> by the runtime? For some reason I remember reading somewhere in the past
> that you can't do this, but I wasn't sure.

Are all your drivers up to date? click for free checkup

26 Sep 2005 7:10 PM

Jas

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.

Show quoteHide quote

"Nicole Calinoiu" wrote:

> Yes and no. There are ways to read the permission grant, but they all
> require at least one "dangerous" permission, so they tend to be somewhat
> useless for reading the permission grant of a limited-permission assembly
> from within the target assembly itself. However, if you can somehow involve
> a highly privileged assembly in the process, one of these may work for you.
>
> There are also some other options for detecting whether a specific
> permission (or set of permissions) has been granted to a given assembly
> which, depending on what you're trying to do, may be a better approach.
> So... In what scenario do you need this information, and what would you do
> with it once you've got it?
>
>

27 Sep 2005 12:34 PM

Nicole Calinoiu

"Jas" <J**@discussions.microsoft.com> wrote in message
news:2903D28B-C4C6-4220-8EE6-AC2761264D35@microsoft.com...
> 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.

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.

> I could use imperative syntax to
> assert permissions in try catch block,

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.

Show quoteHide quote

> but I was wondering if there is a more
> elegant way to do this with support from the runtime.
>
> "Nicole Calinoiu" wrote:
>
>> Yes and no. There are ways to read the permission grant, but they all
>> require at least one "dangerous" permission, so they tend to be somewhat
>> useless for reading the permission grant of a limited-permission assembly
>> from within the target assembly itself. However, if you can somehow
>> involve
>> a highly privileged assembly in the process, one of these may work for
>> you.
>>
>> There are also some other options for detecting whether a specific
>> permission (or set of permissions) has been granted to a given assembly
>> which, depending on what you're trying to do, may be a better approach.
>> So... In what scenario do you need this information, and what would you
>> do
>> with it once you've got it?
>>
>>

28 Sep 2005 2:55 AM

Jas

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.

Show quoteHide quote

"Nicole Calinoiu" wrote:

> "Jas" <J**@discussions.microsoft.com> wrote in message
> news:2903D28B-C4C6-4220-8EE6-AC2761264D35@microsoft.com...
> > 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.
>
> 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.
>
>
>
> > I could use imperative syntax to
> > assert permissions in try catch block,
>
> 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.
>
>
>
> > but I was wondering if there is a more
> > elegant way to do this with support from the runtime.
> >
> > "Nicole Calinoiu" wrote:
> >
> >> Yes and no. There are ways to read the permission grant, but they all
> >> require at least one "dangerous" permission, so they tend to be somewhat
> >> useless for reading the permission grant of a limited-permission assembly
> >> from within the target assembly itself. However, if you can somehow
> >> involve
> >> a highly privileged assembly in the process, one of these may work for
> >> you.
> >>
> >> There are also some other options for detecting whether a specific
> >> permission (or set of permissions) has been granted to a given assembly
> >> which, depending on what you're trying to do, may be a better approach.
> >> So... In what scenario do you need this information, and what would you
> >> do
> >> with it once you've got it?
> >>
> >>
>
>
>

9 Oct 2005 1:23 PM

Nicole Calinoiu

"Jas" <J**@discussions.microsoft.com> wrote in message
news:06A864B0-7071-4D0C-8E3E-859539C59725@microsoft.com...
> 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,

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

Show quoteHide quote

> 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.
>
> "Nicole Calinoiu" wrote:
>
>> "Jas" <J**@discussions.microsoft.com> wrote in message
>> news:2903D28B-C4C6-4220-8EE6-AC2761264D35@microsoft.com...
>> > 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.
>>
>> 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.
>>
>>
>>
>> > I could use imperative syntax to
>> > assert permissions in try catch block,
>>
>> 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.
>>
>>
>>
>> > but I was wondering if there is a more
>> > elegant way to do this with support from the runtime.
>> >
>> > "Nicole Calinoiu" wrote:
>> >
>> >> Yes and no. There are ways to read the permission grant, but they all
>> >> require at least one "dangerous" permission, so they tend to be
>> >> somewhat
>> >> useless for reading the permission grant of a limited-permission
>> >> assembly
>> >> from within the target assembly itself. However, if you can somehow
>> >> involve
>> >> a highly privileged assembly in the process, one of these may work for
>> >> you.
>> >>
>> >> There are also some other options for detecting whether a specific
>> >> permission (or set of permissions) has been granted to a given
>> >> assembly
>> >> which, depending on what you're trying to do, may be a better
>> >> approach.
>> >> So... In what scenario do you need this information, and what would
>> >> you
>> >> do
>> >> with it once you've got it?
>> >>
>> >>
>>
>>
>>