I have various projects that use reflection to access and invoke private or internal members in some of the framework classes.
These projects all work fine on my machine (running visual basic express 2008), but are they guaranteed to work on another machine, or, say, over a network?
I've had a look at ReflectionPermission, but I'm not sure if I need that granting to me or if I grant it to my project!
I'm not as stupid as this question sounds, honest!
The computer where the program runs needs to grant ReflectionPermission to the program.
This will be no problem if the user runs your program from the local filesystem. It may be a problem if the user runs your program from a network share, an intranet, the Internet, etc. depending on the policies of the computer where the program runs. Policies may also consider factors such as the originating URL or network share, whether the program is signed, etc. For example, if this is an intranet app, the network admins may allow high trust to programs that originate from http://our_site/approved_apps/ and are signed, but not to programs that originate from other parts of the intranet or are unsigned.
In any case, it is outside your control: your assembly can state that it needs ReflectionPermission, but whether it is granted is up to the configuration of the target system. (But again, if your program runs from the local file system, it shouldn't be a problem because it will then run with full trust unless someone has really locked down the machine.)
They should work fine on any machine as long as it is run from a local drive. By default running the executable from a network share on .NET up to 3.5SP1 would run you in a reduced trust mode (either Internet or Intranet) and you would not have access to the ReflectionPermission which means you will not be able to access protected or private members.
From 3.5SP1 onwards they have changed the operation of executables to give them full trust if run directly (as opposed to be loaded into another process via Assembly.Load and similar).
You can also grant specific permissions to an assembly using the caspol tool which is part of the framework. See this for more info about caspol.
If you can execute the code then you should be able use reflection to interrogate it.
From my reading of the ReflectionPermission MSDN page it seems that you need to use this to gain access to all members of objects:
Without ReflectionPermission, code can use reflection to access only the public members of objects. Code with ReflectionPermission and the appropriate ReflectionPermissionFlag flags can access the protected and private members of objects.
Related
I am trying to get my silverlight application running with elevated privileges in browser. However, no matter what I do, it doesnt get elevated.
I have tried to add registry key AllowElevatedTrustAppsInBrowser (as DWORD with value 1), and signed the XAP file using VS 2012. I also came across a blog that mentioned the clientaccesspolicy.xml file, but I was not able to allow elevated privileges with this either. I put the xml file inside the web project hosting the html file that displays the XAP.
Has anyone actually managed to get this to run?
I also tried following this: http://mtaulty.com/CommunityServer/blogs/mike_taultys_blog/archive/2011/04/27/silverlight-5-beta-rough-notes-trusted-apps-in-the-browser.aspx but im unsure about where to run the commands he runs on windows.
There is a good summary on how to enable in-browser elevated trust by Mister Goodcat here, where he also provides some troubleshooting tips:
One thing to keep in mind is that even if your application runs as trusted in-browser app, it is still subject to the security restrictions the browser itself imposes. That means that its possibilities may be much more restricted than if they ran out of browser, for example by Internet Explorer's Protected Mode. In addition, the Silverlight runtime itself restricts use of certain features for in-browser trusted apps, for example you cannot use the Window class and/or create additional windows when you're running in the browser.
If none of the above applies to you and you still run into problems, one thing to do is check whether your certificate(s) have been installed correctly. There's a snap-in for the management console for this. Here is an article that describes how to get there (note that you should add a snap-in for your user account, not the computer account as in this description).
You can also check whether your registry key is actually and successfully queried, for example by using a tool like Process Monitor from the Sysinternals Suite. Watch for operations of type "ReqQueryValue" of your browser executable that access the key we created above, and make sure the Result is "SUCCESS".
I want to run an exe on client system from my c# asp.net website. When I use Process.Start()
it throws an error:
The requested operation requires elevation.
How do I set permissions to run that exe?
You can't spawn processes on the client machine from server-side code.
When you use Process.Start in server-side code, it is attempting to execute the process there, on the server where the website is hosted. If you wanted to create processes on the clients computer then you would need to expose a download for them (and not in employing subterfuge, like malign sites might do to install software - supply it gracefully, and normally (and with permission)), or a Silverlight application or something along those lines.
The bottom line is that the code you want to execute (even if that is just to spawn a process) must reside on the client, and be executed there.
You can't run an application from a web server like that. You will have to have the user download the application by supplying the EXE, a setup file or using ClickOnce.
Or you can develop an ActiveX control that you can have the browser automatically download from a Trusted Internet Zone.
Once downloaded, proper signing with a certificate (signed from the trusted (corporate) root certificate) will avoid the user getting a prompt to ask whether he wishes to allow the ActiveX control to install/be activated -
The ActiveX control can subsequently do anything the interactively logged on user could. This means that to actually install a program you'd need to elevate (UAC on Vista+); But if the goal was just to run a standalone executable, you should be good to go.
This all assumes white-hat purposes in a (larger) corporate setting, because it relies on PKI infrastructure and central browser policies, to name just two.**
This would, really, lead to some excellent questions on serverfault or superuser
I noticed you said you wanted to run an exe file on the client, but you didn't say explicitly that the exe is on the server and you want to push it to the client. Everyone seems to be assuming that is the case.
You CAN accomplish this fairly easily with a small JavaScript if you have a few prerequisites:
The executable is already present on the client machine.
All of your clients are running IE
You can enforce a policy to put your site in the Intranet or Trusted
Sites zone.
So basically this means it's a corporate intranet application. I am assuming this is probably the case since, well, if you were expecting to do this with a public app, I would be surprised.
For the script to accomplish this, please see my answer to this question:
How can I get a program on a client machine to run from an ASP.NET page?
Curious to know why my 2.0 .net application is being allowed to execute when I have restricted the permissions assigned to the assembly.
I've created a new Code Group at the Enterprise level which will match for any assembly with a particular digital signature. The code group has been set so that only permissions from the associated permission set will be used and also that lower policy levels will not be evaluated.
Running the .Net 2.0 PermCalc states that my application needs the following permissions:
UnmanagedCode,
Environment
FileIO
Registry
Reflection
I've assigned to my custom code group the permission for unmanaged code but nothing else.
The first method in my application demands all of the above permissions upfront so I can display a sensible message to the user before exiting.
Running the .NET 2.0 Configuation "Evaluate Assembly" tool on my assembly indeed shows that my application will only be given the UnmanagedCode permission.
However when I execute my application is runs and completes, quite obviously doing various FileIO and Registry operations.
My app is signed with the digital signature that should match the restricted code group.
Can anyone explain why this works.
Note: My ultimate aim is to make sure that my application does not crash horribly if executed from a network share. I would have liked to check the assembly evidence zone is My_Computer but I can no longer do that with .NET 3.5 SP1. See FullTrust On the LocalIntranet
Thanks in advance for any help/suggestions.
If you have configured your CAS policy correctly, then chances are that your application isn't being denied the permissions you expect because it is not being run under the CLR whose policy you configured. Do you perhaps have 32-bit and 64-bit CLRs installed on the same machine?
Another possibility might be that your "early check" demand is in the wrong place. Is it directly in your application's Main method? If so, when the demand runs, there won't be any of your application code on the call stack that is verified. If this is the problem, simply moving the demand into another method invoked from Main should allow the demand to fail.
you can still check the assembly evidence zone in .NET 3.5 SP1 - http://msdn.microsoft.com/en-us/library/system.security.policy.zone.aspx.
For what caspol allows your assembly see http://msdn.microsoft.com/en-us/library/tx1dts55.aspx.
This http://blogs.msdn.com/b/brada/archive/2007/10/26/adhoc-poll-allowing-net-exes-to-run-off-a-network-share.aspx could affect what you see...
EDIT:
For checking when running from a network share you can still get Assembly.GetExecutingAssembly().Location and then check whether it a UNC or netowrk drive via DriveType for your location System.IO.DriveInfo[] (i.e. System.IO.DriveType.Network).
We have a .NET WinForms application that has several .NET dll's it depends on, running on an XP machine, that is connected to a network in a large domain.
We deployed this application on a customers machine while logged in as an admin and all worked fine.
We then logged into a lower privalaged account, and low and behold the application failed to start, but that was expected.
So, we got their IT department to make the folder Read/Write access (as we use folders in there for holding temp files) and they allowed the .exe to be executable by that user.
Now starting the executable, the application runs (yay) but then we got it to perform an action that required code in one of it dependant (managed) dll's...
An Exeception is thrown, stating "The assembly "xxxx.dll" failed to load (access is denied)" I am assured by their IT department that the dll's have the same file permissions as the main executable (and by quick look at what the lower privilege user can see of security settings, it did appear that way) and they were not set as "blocked" as XP sometimes does.
So the question is more of a fish for possible ideas that may be causing this...
EDIT: Turns out it was file permissions that were the problem and that the IT department in question hadn't followed through checking that permissions had been applied to all child objects. As I can't accept all 4 of your answers for such good ideas I have given you all an up vote.
The user may have access to the DLL listed in the error message but do they have access to all of the DLLs that that DLL needs? Check out something like Dependency Walker to find any DLLs that might be required.
Several possible problems, some detailed here: http://msdn.microsoft.com/en-us/library/ab4eace3.aspx
You may be asking to load an assembly that makes security demands that are larger than your main application. (Requesting permissions: http://msdn.microsoft.com/en-us/library/yd267cce.aspx )
If you are running full trust this is unlikely, but if the DLL you are loading is on the network make sure you have that location trusted by .NET: (trusting a share: http://blogs.msdn.com/shawnfa/archive/2004/12/30/344554.aspx )
Does the DLL access the registry or some other system folder that the lower privilege user isn't allowed to access? What is it trying to do when the error occurs?
You could also check whether the domain has some kind of group policy that's interfering with what the DLL is trying to do.
.NET doesn't trust assemblies from non-local drives by default.
See http://msdn.microsoft.com/en-us/library/zdc263t0.aspx for instructions to allow specific network locations to be trusted.
I'm architecting a WPF application using the PnP Composite Application Guidance. The application will be run locally, within our intranet.
Modules will be loaded dynamically based on user roles. The modules must therefore be accessible to the application through a network share, thus accessible from the client machines.
What I'd like to do is keep all the module .dlls in a location not accessible to staff, but still be able to provide them to the composite application when demanded and when the current user is authenticated to use that module.
My thought is to load the .dlls by streaming them down from a WCF service, where the WCF service (on the server) can access the .dll repository, but none of the client machines can access it. Authentication would also be handled by the service.
I suspect that I might be overcomplicating things somehow.
Is this something that can be done with a simple filesystem configuration and programmatically passing credentials when accessing the shared folder? If I do this, would access only be granted to the calling application, or would the logged-on user now be able to navigate to the shared folder?
Is this, in any way, a solved problem with MEF or any other project of which you're aware? (I hope this isn't LMGTFY-worthy -- I haven't been able to come up with anything.)
At Argonne National Laboratory we keep all sharable DLL and other objects (.INI files, PowerBuilder PBD libraries, application software, etc.) on a simple and internally public file server and objects are being downloaded over the network on a per need basis as defined by each client/server application. Thus we are minimizing the maintenance of middleware (Oracle Client, PowerBuilder, Java, Microsoft, ODBC, etc.) to a single file server location with basically no software installed on the end user PC. Typically we physically download less than a few KB Registry Keys to the individual end user PC; this includes the full Oracle Client, which if installed on the PC alone would take up 650+ MB disk space and several thousand Registry Keys, and costly to maintain on the enterprise. Instead our Oracle Client on the PC is about 17KB.
The only “software" on the client side are Registry Keys containing variables pointing to server locations (f.ex. ORACLE_HOME: \<server name>\ORACLE\v10\Ora10g ).
This has been a very cost effective solution we have been using for 10+ years, making all middleware and application software upgrades totally transparent to more than 2000 users Lab wide. Over the years we have done thousands of object upgrades on the central file server without ever having to install a single upgrade on the end user Desktop. Although this has some risks (“thou shall not copy DLLs over the network”, etc.) and is a heavily customized solution, it has worked flawlessly for us throughout for a large number of applications and middleware.
This is a somewhat surprisingly simple solution in today’s advanced technology, but it has been totally efficient and cost effective for us. Several vendors (Citrix and others) have looked at our solution somewhat perplexed, but every vendor of deployment techniques who have seen our deployment has come to the same conclusion, basically: “you do not need us”.
when loading modules you need to keep in mind that:
Once loaded, an assembly can't be unloaded (unless you unload the entire application domain) - so if users can log in and out using the same instance, you may have a problem.
"the load context" matters (see http://blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx) - this may cause problems if you have dependencies between modules or dependencies on assemblies that are not in the "load context"
If the restricted access to dlls is due to a licensing issue, maybe you need to refine the licensing mechanism somehow (not tie it to access to the actual code, but to some other checks)?