I'm looking for a way to run a GUI program with admin privileges from an already privileged process (as with a service running as SYSTEM) - without having a prompt for admin password.
What I know is that if a service as SYSTEM runs a GUI program, the process will start, but it won't be displayed for the user.
Having read about impersonation and window stations and desktops, I'm wondering if the SYSTEM service would be able to launch a GUI program, and then somehow create a new process and then set it's window station and desktop to the default one where the user can interact with it.
The use-case would be to open a program installation (which would require admin rights to install for all users - or to install at all) and then with some simulated keystrokes go through the installation setup (which is why it's important to have a GUI that can be interacted with).
Is something like this even possible in the context of it being run as a SYSTEM process?
I've developed an Accessibility API console application in C++ for High Sierra (and lower) - uses AXUIElementCopyAttributeValue etc.
I've disabled SIP to give me a chance here to write to the Accessibility database using tccutil.
So, the application runs as expected in Xcode, given that I've enabled 'Xcode' in System Preferences->Security & Privacy->Privacy->Accessibility.
I've wrapped my console application into a .app so I can drag and drop into this Accessibility panel.
If I run the application outside of Xcode in a Terminal window, I have to also give Terminal.app Accessibility rights for the application to use the API otherwise nothing is extracted. This then seems that you must give the calling application the rights.
I'm trying to launch the application on startup via a LaunchAgent with root privileges, /usr/bin/sudo being the calling application. Launching a script instead to run the application seemed the better method. The application launches fine, infact the console application inside the .app is also added now to the Accessibility panel.
Unfortunately, the Accessibility side of things is still not working and I've run out of ideas?
Any help will be appreciated.
Many thanks in advance.
I'm writing a C/C++ program that I'd like to have run when a user logs on to their Mac or Linux machine.
I'm thinking of starting my app when kernel finishes loading. This app will be listen user login signal. When it receives the signal, it will then run my other app.
Is this a good strategy? Is there a better way to have my app automatically run when a user logs on to their machine?
Yes, there are better ways:
For Mac OS X you want to use launchd(8). (See Apple's Daemons and Services Programming Guide and the man page for launchd(8).)
For KDE there is Autostart.
For Gnome you can use the Default Session or the system wide Configuration of the GNOME Display Manager.
In the old days of X11 there used to be a file called .xinitrc (see the man page for xinit(1)) or .xsession (see the man page for xdm(1)).
You could set up a cron job to observe the logged in users, and when the list changes, act accordingly.
I'm am developing a Firefox extension which interfaces with an underlying Windows service (which I have already made).
During the development so far I encountered one bug in the installer program (which installs the FF extension AND the service). This was due to the security model on Vista requiring elevated privileges to be able to install and start the service. I adjusted the installer and now it installs fine (just with additional Vista'esque warning dialogs being displayed to end-users - which I can live with !)
I am now in the process of developing an XPCOM component that will install along with the XUL stuff I have already made. There will be a XUL javascript interface to the XPCOM which will try to do things like stop and start the service (e.g when user-configuration data is changed).
My question: Since FF will normally be run under a user account, will I run into any difficulties on Vista or other Windows flavors trying to start or stop my own service via XPCOM?
(When users run the installer I don't mind security dialogs popping up in Vista. But I certainly don't want this to happen whenever they try to change their info in the XUL interface.)
What is the correct way to go about this?
Yes, if your service is running as an Administrator then the Firefox process, running as a normal user will not be able to start or stop it. However, it appears that you can use the "sc" command to set access controls on your service from your installer, which means you can allow non-admin users to start and stop your service.
You'll need to use "sc sdset", which is documented (lightly) here:
http://technet.microsoft.com/en-us/library/cc742037%28WS.10%29.aspx
However, to use that, you'll need to read up on the "Security Descriptor Definition Language", which looks kind of complicated:
http://msdn.microsoft.com/en-us/library/aa379567%28VS.85%29.aspx
This blog entry appears to have some human-readable information on it:
http://blogs.dirteam.com/blogs/jorge/archive/2008/03/26/parsing-sddl-strings.aspx
I have written a Windows service that allows me to remotely run and stop applications. These applications are run using CreateProcess, and this works for me because most of them only perform backend processing. Recently, I need to run applications that present GUI to the current log in user. How do I code in C++ to allow my service to locate the currently active desktop and run the GUI on it?
Roger Lipscombe's answer, to use WTSEnumerateSessions to find the right desktop, then CreateProcessAsUser to start the application on that desktop (you pass it the handle of the desktop as part of the STARTUPINFO structure) is correct.
However, I would strongly recommend against doing this. In some environments, such as Terminal Server hosts with many active users, determining which desktop is the 'active' one isn't easy, and may not even be possible.
But most importantly, if an application will suddenly appear on a user's desktop, this may very well occur at a bad time (either because the user simply isn't expecting it, or because you're trying to launch the app when the session isn't quite initialized yet, in the process of shutting down, or whatever).
A more conventional approach would be to put a shortcut to a small client app for your service in the global startup group. This app will then launch along with every user session, and can be used start other apps (if so desired) without any juggling of user credentials, sessions and/or desktops.
Also, this shortcut can be moved/disabled by administrators as desired, which will make deployment of your application much easier, since it doesn't deviate from the standards used by other Windows apps...
The short answer is "You don't", as opening a GUI program running under another user context is a security vulnerability commonly known as a Shatter Attack.
Take a look at this MSDN article: Interactive Services. It gives some options for a service to interact with a user.
In short you have these options:
Display a dialog box in the user's session using the WTSSendMessage function.
Create a separate hidden GUI application and use the CreateProcessAsUser function to run the application within the context of the interactive user. Design the GUI application to communicate with the service through some method of interprocess communication (IPC), for example, named pipes. The service communicates with the GUI application to tell it when to display the GUI. The application communicates the results of the user interaction back to the service so that the service can take the appropriate action. Note that IPC can expose your service interfaces over the network unless you use an appropriate access control list (ACL).
If this service runs on a multiuser system, add the application to the following key so that it is run in each session: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. If the application uses named pipes for IPC, the server can distinguish between multiple user processes by giving each pipe a unique name based on the session ID.
WTSEnumerateSessions and CreateProcessAsUser.
Several people suggested WTSEnumerateSessions and CreateProcessAsUser. I wonder why no one suggested WTSGetActiveConsoleSessionId, since you said you only want to target one logged in user.
Several people sure are right to suggest CreateProcessAsUser though. If you call plain old CreateProcess the way you said, then the application's GUI will run with your service's privileges instead of the user's privileges.
That problems Session 0 , Interactive Services ,
Windows Service Allow Service To Interact With Desktop
on Windows 7 or Windows Vista
You can read this article
http://www.codeproject.com/KB/vista-security/SubvertingVistaUAC.aspx
I try explained here it's working on Windows 7
On Win2K, XP and Win2K3 the console user is logged on in Session 0, the same session the services live in. If a service is configured as interactive, it'll be able to show the UI on the user's desktop.
However, on Vista, no user can be logged on in Session 0. Showing UI from a service there is a bit trickier. You need to enumerate the active sessions using WTSEnumerateSessions API, find the console session and create the process as that user. Of course, you need also a token or user credentials to be able to do that. You can read more details about this process here.
I think as long as you have only one user logged in, it will automatically display on that user's desktop.
Anyway, be very careful when having a service start an exe.
If the write access to the folder with the exe is not restricted, any user can replace that exe with any other program, which will then be run with sytem rights. Take for example cmd.exe (available on all windows sytems). The next time the service tries to start your exe, you get a command shell with system rights...
If you launch a GUI from your service it will show up on the currently active desktop.
But only if you adjusted the service permissions: You need to allow it to interact with the desktop.
Important Services cannot directly interact with a user as of Windows Vista. Therefore, the techniques mentioned in the section titled Using an Interactive Service should not be used in new code.
This is taken from : http://msdn.microsoft.com/en-us/library/ms683502(VS.85).aspx