Re: enumerate runtime permissions

From: Jas (Jas_at_discussions.microsoft.com)
Date: 09/28/05 

Date: Tue, 27 Sep 2005 19:55:04 -0700

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.

"Nicole Calinoiu" wrote:

> "Jas" <Jas@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?
> >>
> >>
>
>
>

Relevant Pages

  • RE: SecurityException "Request Failed"
    ... >LinkDemand extremely likely to fail. ... >>Does the invoked method have all the asserted permissions ... The stack walk will hit your assert, ...
    (microsoft.public.dotnet.security)
  • Re: CAS newbie
    ... It appears that you may need to assert more than ... If you are impersonating, then you will likely need to implement Kerberos ... Joe Kaplan-MS MVP Directory Services Programming ... code group to give full trust permissions to that dll. ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: Security Settings to load Winform using unmanaged code in IE?
    ... try removing assembly declarations and see ... This posting is provided "AS IS" with no warranties, and confers no rights ... > The comment on Assert is important when insecure code is called - My ... > code DOES Assert privieleges when permissions are required. ...
    (microsoft.public.dotnet.security)
  • Re: Remoting from a control hosted in IE
    ... Asserting permissions almost certainly won't help with this, ... and client (the control) subscribes to this event. ... > but what permissions and where do I assert them - I have no clue. ... An error occurred while processing the request on ...
    (microsoft.public.dotnet.security)
  • Re: USERS group has the ability to change security permissions???
    ... Please use the Advance view in the NTFS permissions dialog to ... When there is a generic grant and a special grant to the same entity ... the RESULT: user level access can change NTFS ...
    (microsoft.public.win2000.security)