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".
Related
I just try to understand the Google update service (aka Omaha) and can't find any information about how Omaha updates Chrome without the UAC Prompt?! Or without any Administrator privileges.
I am looking for a way to lunch a update service that can Update a Application in the Program folder (without UAC / Administrator privileges) just like Omaha does, but i can't find any documentation regarding that topic. Tried browsing the source code a bit thought but i couldn't find anything that helps.
In fact only the Installation should require Administrator Rights, but the update should not.
Any "easy" way to achieve this in C#?
Chrome installs a Windows Service, which is always running and preforms the update. The service runs as SYSTEM and so can perform the update without UAC prompt.
See:
https://support.google.com/installer/answer/98805?hl=en
http://omaha.googlecode.com/svn/wiki/OmahaOverview.html (Execution model section)
I would like to enumerate child windows of a given process to check for dialog windows. For reasons I won't go into here, if it finds any, I'd like to subsequently kill that application.
Running a standalone application to do this works without any issues. The application has access (via some P/Invoke calls) to a process's windows and I can subsequently kill that application.
Running the same code as a service, however, does not work as expected. It seems that the user running the service is not able to interact with the desktop (which is a setting I can only see for the LOCAL system account).
Does anyone know of any workarounds to this? Is it possible for me to enumerate a process's windows from a windows service?
FYI -- the code (at least an adaptation of) I'm using is available here: https://stackoverflow.com/a/1405088/2115261
You're probably running Windows 7 (or 8 or Vista), because the ability for Windows Servcies to interact with the desktop was last supported in Windows XP.
There is a white paper on MSDN that describes the changes made for Vista and upwards. Basically, it is now not possible to interact with the desktop in any way.
However, there is an example on CodeProject that demonstrates how to interact with the Task Scheduler from a Windows Service, and the process executed by the Task Scheduler can interact with the desktop. Perhaps this would be a suitable workaround for you.
You can only enumerate windows on the same terminal services session (aka Remote Desktop session) as your process. However, given appropriate privilege, you can launch a subprocess in another terminal services session to do the work on your behalf, although you need to be aware of the potential security issues depending on how you do this.
Assuming that you've already got a handle to the target process, the simplest approach would be to use OpenProcessToken to get a token in the target session, DuplicateTokenEx to duplicate it, and CreateProcessAsUser to launch the subprocess. Since all you need is a yes/no answer, you can use the process exit code rather than needing an IPC mechanism.
Security implications: since your subprocess is running in the user's context, a knowledgeable user could prevent it from running properly. Also, if you do use an IPC mechanism, you'd have to treat the input from the subprocess as untrusted (check for buffer overruns, etc.).
An alternative approach would be to launch a subprocess in your own context but in the target session. IIRC, you can do this by duplicating your own token and using SetTokenInformation on the duplicate to change TokenSessionId before launching the subprocess with CreateProcessAsUser.
Security implications: the subprocess, and through it the service process and the service account, could be subject to shatter attacks (malicious window messages) and other risks, although the integrity level mechanism may mitigate this to some extent. It is my understanding that creating a separate window station and desktop (with appropriate ACLs) eliminates these risks, but I'm not sure offhand of the impact on the code you want to run. Another mitigation would be to use CreateRestrictedToken to remove all groups and privileges from the token before launching the subprocess.
Unless it is absolutely essential that the user not be able to subvert your ability to detect the existence of the dialog window, I strongly recommend the first approach.
If you give the service a local system account to log on with, you will be able to tick the "Allow service to interact with desktop" checkbox in the service's properties (from Service Control Manager).
See the "Log On" tab of the Service's Property Pages.
That might work for you. But unfortunately, it probably won't. Still worth a quick try?
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?
I have a C# application that I am writing that will go repair broken registry keys across the organization. I am trying to use the three classes of RegistryKey, RegistrySecurity and RegistryAccessRule and when I try to use them I get a "Requested registry access is not allowed.". I have searched this extensively and cannot find a good solution.
The key's I am trying to fix, have no permissions on them (see screenshot below). They are blank and have no inheritable settings. This doesn't allow me to fix them with my app as I have no permissions, but I can change the permissions with the user I run this application as if I open regedit. So I know I can add permissions to broken machines by manual means with this user, but for some reason my application no matter how hard I tell it to elevate itself cannot get the permissions.
Things I have tried:
On Windows 7 it works when you run the application with UAC, right click run as administrator. I would like to duplicate being able to do this on Windows XP with the same code.
I have created a manifest using level "highestAvailable" and also trying "requireAdministrator".
I have also tried using "System.Security.Permissions.RegistryPermission" assert which apparently will bring higher level of permissions to run as well.
I am not running this from a network share, although I have tried both local and network to see what security zone it would run from matters.
You can see what the permissions look like below:
http://i.stack.imgur.com/0c99s.jpg
Any help is appreciated!
You could try impersonating an administrator account from within your code, using P/Invoke to call the necessary api's like this person did to create an account impersonation class:
Impersonator Class c#
I found this nice snippet of code online:
rkApp = Registry.LocalMachine.OpenSubKey("SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run", true);
Which runs great but alas on windows 7 and vista I suspect, it crashes cause it doesn't have permission to write there.
So then I research (on stackoverflow of course) how to avoid this, quickest method:
rkApp = Registry.CurrentUser.OpenSubKey("SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run", true);
Simple enough! Though there is two issues remaining. One is with both methods (on a XP Box that is), the program thinks its relative path is somewhere in the C:\windows folder now...so I.e. it won't find my path relative help files etc. The second issue is, on windows 7, my program won't startup until I log in. I want it to start up in the background if possible before anyone logs in.
Its a simple .exe that hangs out in the systray when its running. I didn't want to create this monstrosity of an installer to get around these admin and pathing issues.
I Think I would have to create it as a service (no clue how to do that) to get it to start up when the machine reboots before anyone logs in. Secondly to do that I am sure I have to figure out the admin privileges, and since I don't want to have to approve the program to run every time it starts up it sounds like I would have to figure out its admin privileges during install time, but alas no installer.
So just curious what routes I might take to get this to work. I can even suffer it coming up only after when the user logs in, but my current methods that work this way really screw up the pathing of my program since it tries to write stuff out to a new directory (not the one I originally started the EXE from). Etc...and I have no clue how to go about fixing that pathing issue.
It sounds like you need two programs here.
You can't have an application run in the system tray and run prior to login. The system tray doesn't "exist" until the user logs in and has a valid desktop.
The normal way to handle this is to make two programs. First, create a windows service that does the bulk of your work. This will run on startup, and be independent of any user logins.
Then, make a user mode application which uses IPC to communicate with the service. This can run on login, and "talk" to the service remotely, thereby providing your system tray requirements.
If you want your program to start as a service before anyone logs on, then it's going to need to be installed and run as an admin user. There's not getting round this fact.
There's a Microsoft Knowledge Base article on creating a service which should get you started.
There's a project template for a Windows Service installed by default in Visual Studio 2008:
"File > New > Project > Visual C# > Windows > Windows Service"