HighTechTalks DotNet Forums  

AddDomain with FullTrust

Dotnet Security microsoft.public.dotnet.security


Discuss AddDomain with FullTrust in the Dotnet Security forum.



Reply
 
Thread Tools Search this Thread Display Modes
  #1  
Old   
Joel Lucsy
 
Posts: n/a

Default AddDomain with FullTrust - 03-04-2005 , 09:17 AM






Hello,

Is it possible to create an AppDomain with FullTrust permissions? I'll
be hosting the .NET runtime in an unmanaged program, but since my
program will typically be run from the network, I'd like to reduce the
"administration" overhead of having to modify the policies.
Thanks.

--
Joel Lucsy
"The dinosaurs became extinct because they didn't have a space program."
-- Larry Niven

Reply With Quote
  #2  
Old   
AT
 
Posts: n/a

Default Re: AddDomain with FullTrust - 03-04-2005 , 10:38 AM






The short answer is yes.
The long answer is that unamanged application can only have "FullTrust"
or no trust. If the application is permitted to run it is granted full
trust, depending on the location of the unmanaged application, your OS
and service pack level the user *might* be prompted to allow the
application to run, XP SP2 will not even ask the user to run an
unmanaged application from an untrusted source such as the internet it
will simply block the applicaiton and preventing it from doing anything
at all, so as far as "simplifying deployment" you have not found a way
to bypass the security policy you have only reduced the granularity of
the permission request, run or do not run. A managed host on the other
hand can be pre-granted a defined permission set such as full trust
from a local intranet site in which case the application is not blocked
nor is the user prompted it just runs, the less permissions your
application requires the more likely the user will be able to grant the
application permission to run. If the application requires full trust
the user can install it on his machine or an administrator can
pre-grant the assemlby permissions to run from the local intranet.
However, if the assembly only requires execute permissions the default
policy will permit the assembly to run from the local intranet without
any additional steps, confirmation dialogs, or whatever.

- Kurt


Reply With Quote
  #3  
Old   
Joel Lucsy
 
Posts: n/a

Default Re: AddDomain with FullTrust - 03-04-2005 , 03:09 PM



kurbylogic (AT) hotmail (DOT) com wrote:
Quote:
The short answer is yes.
- Kurt

Well, in short, you're wrong, or at least I'm not seeing the behavior
you described. The unmanaged host shows the exact same behavior as
running the assembly directly, i.e. it throws a security exception for
the native p/invoked library. If I grant the right zone permissions,
both work, managed and unmanaged.
I could be writing the unmanaged host wrong, but I'm not seeing a full
trust/no trust dichotomy. I'm doing the standard CorBindToRuntime,
CreateDomain,ExecuteAssembly. I'm suspecting that I need to create the
Evidence, or perhaps SetAppDomainPolicy, but so far I can't get it work.
So, does anyone have any examples of "opening" the permissions instead
of further restricting them?

--
Joel Lucsy
"The dinosaurs became extinct because they didn't have a space program."
-- Larry Niven


Reply With Quote
  #4  
Old   
AT
 
Posts: n/a

Default Re: AddDomain with FullTrust - 03-04-2005 , 11:58 PM



A PermissionSet is granted to an *assembly* not an appdomain. You
cannot grant more permissions then you already have, so you must have
full trust in order to grant full trust however just because the host
has full trust does not imply everyone else will too. When an assembly
is loaded the policy manager determines the grant set based on the
grantset based on the interesection of the enterprise, machine, user,
and appdomain policies using host provided evidence if any, and
internally determined evidence such as the location of the assembly and
strong name. A lower level policy such as appdomain level cannot grant
more permissions to an assembly then would be granted by the user,
machine, or enterprise level policies. An unmanaged or managed host
with ControlEvidence can provide additional evidence for use in policy
evaluation, this is generally used to reduce rather then increase
permissions, such as Zone, Site, and Url evidence can then be used by
the security policy to reduce the granted permission set, however one
can also use this evidence to increase the permissions granted by the
security policy, for example add a site based codegroup to grant
www.xyz.org everything permission instead of nothing. As an unmanaged
host you have ControlEvidence permission and can add custom evidence,
however an unmanaged host can only provide appdomain evidence so this
doesn't really buy you anything as far as granting permissions that are
not already granted by the machine policy. So as I said before I don't
think this approach does anything as far as reducing the administrative
overhead of tweaking security policies, if you want to grant full trust
to an assembly not located on the local machine you must modify the
polciy or install the assembly on the local machine.

- Kurt



Joel Lucsy wrote:
Quote:
kurbylogic (AT) hotmail (DOT) com wrote:
The short answer is yes.
- Kurt


Well, in short, you're wrong, or at least I'm not seeing the behavior
you described. The unmanaged host shows the exact same behavior as
running the assembly directly, i.e. it throws a security exception
for
the native p/invoked library. If I grant the right zone permissions,
both work, managed and unmanaged.
I could be writing the unmanaged host wrong, but I'm not seeing a
full
trust/no trust dichotomy. I'm doing the standard CorBindToRuntime,
CreateDomain,ExecuteAssembly. I'm suspecting that I need to create
the
Evidence, or perhaps SetAppDomainPolicy, but so far I can't get it
work.
So, does anyone have any examples of "opening" the permissions
instead
of further restricting them?

--
Joel Lucsy
"The dinosaurs became extinct because they didn't have a space
program."
-- Larry Niven


Reply With Quote
Reply




Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.4
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.