It was possible to set a hook on all keyboard/mouse events in Windows XP:
SetWindowsHookEx(WH_JOURNALRECORD, (HOOKPROC)JournalLogProc, GetModuleHandle(NULL), 0);
... but in Windows 7, SetWindowsHookEx returning 5 (access denied).
How to set permissions/ACLs the function need? I got the same "access denied" error even if I run my program "As Administrator".
Hooks are not securable objects, so you cannot set an ACL for them. The reason you are getting an error in Win7 is because UAC, which was introduced in Vista, changes the rules of how journal hooks can be used in general.
A journal hook can only be set by an elevated process, and also the process must bypass User Interface Privilege Isolation (UIPI) by using a UAC manifest that sets uiAccess=True. Note that setting uiAccess=True has other ramifications, so be sure you understand what it actually does (see Windows Integrity Mechanism Design for details). It is not enough to simply run the app as an admin anymore.
The only other workaround is to manually change the security policies of the machine to either disable UAC altogether, or to reduce certain security restrictions in the UAC settings.
Related
Let's say app.exe has been built with requireAdministrator manifest as detailed here (this is really needed for a reason that would be out of topic here). When launching the app, when Windows UAC is enabled, there is a normal prompt:
Now this application needs to run on Windows startup: in an Options dialog, there is a "Launch at Windows startup" checkbox that can be checked or not. When checked, it adds a key in the registry in
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
to enable this "launch on Windows startup feature".
Problem: At Windows startup, when app.exe is (automatically) launched in background, there is this UAC dialog box (see screenshot before), which is annoying for the user.
Question: How to make that app.exe can be launched 1. with requireAdminstrator 2. silently at Windows startup ?
What is the clean way to do this? Lots of software do this (indexing software that both run on background since Windows startup, and don't show such a dialog box).
Note: I would like to avoid TaskScheduler method if possible: https://www.sevenforums.com/tutorials/11949-elevated-program-shortcut-without-uac-prompt-create.html
The indexing software "Everything" does show such a dlalog.
The others you are thinking of run only services with admin rights, not UI.
Running a service requires the software to be architected with that intent, ordinary user applications can be started with the service rules with the help of the "at" service, which you already know how to do (Task Scheduler).
You can substitute some other service for Task Scheduler, at the risk of annoying the user through needless duplication, waste of resources, and likely new security flaws.
Set aside your preference, and use Task Scheduler.
Or remove the background parts of your app and write a service to do those instead.
And be very careful when giving your code administrator rights. Any bug can result in subverting the entire security infrastructure. With great power comes great responsibility.
I'm trying to use SetSystemTime (from Kernel32.dll) or alternatively to use TIME from cmd.exe.
Both fail, TIME gives me the error
A required privilege is not held by the client.
I've already used gpedit.msc to add local/Users and also the user itself to security settings/Local Policies/Change the system time.
I tried to enable the privileg with AdjustTokenPrivileges( SeSystemtimePrivilege ...), but I got a GrandPrivilege failed error .
I'm using Win7 x32 Professional.
It's a standard user with admin privileges, but I'm trying to make the time changes without "Run as Administrator", as the program that calls the SetSystemTime function shouldn't be started with "Run as Administrator".
I supposed that the purpose of the Change the system time policy is exactly for this case and it's also described at MSDN
I'm at a loss what to do.
It turns out that although SeSystemTimePrivilege doesn't trigger UAC for a non-administrator, it is still removed from the restricted token that is generated when an administrator logs in. The upshot is that you can use group policy to assign SeSystemTimePrivilege to non-administrative users, but the policy has no effect for an administrative user.
If it is acceptable for the program to require elevation when run by an administrative user, you could use the highestAvailable manifest setting. That way, the program will only ask for elevation if the user is an administrator. Alternatively, you could design the program to ask for elevation only when it actually needs to set the time.
If an elevation prompt is not acceptable, you will have to install a system service to change the system time on your application's behalf.
I'm trying to hook up to an already existing Word window.
Set WordApp = GetObject(, "Word.Application")
If UAC is turned off this works fine. If UAC is turned to "Default", I get an error. "ActiveX component can't create object".
Once thing I noticed in my experimenting is that if Word was started with "Run as Administrator", things work normally. Unfortunately the box/login I'm expected to run on likely won't have admin rights.
This sounds like an issue developers were educated on back in 2006.
You want both processes to have the same integrity level. It sounds as if you are testing within the IDE running elevated, which should normally be the case. When that is true then the process you want to automate must also be elevated.
This shouldn't be an issue when running normally, since both processes would typically by run at the same level, standard user. If you need something other than this then you need a manifest with uiAccess = True and your code must be signed and formally installed.
See User Interface Privilege Isolation (UIPI) and integrity within Windows Integrity Mechanism Design.
But automating Office has been deprecated for a very long time.
Firstly I want to emphasize that I'm not trying to do anything "nasty" or "hackerish", nor am I trying to hide anything from user here.
During installations (using InstallShield LE) of my application user is prompted by Windows UAC to allow it to run in Administrator mode; If user accepts it - installation continues (standard behavior) and user again can check the option to add this program to autorun list (by adding a registry key to HKLM/../Run). All is fine and normal. But after every Windows restart, when this application starts, UAC kicks in and asks for user permission. Question is, how to avoid it, since it's a bit annoying (yet my app needs Administrator privileges to run)?
I mean user already granted such permissions on installation, so I cannot see a reason why it needs to be prompted on every startup? Moreover, I believe most antivirus software and such, also require elevated permissions to operate, but UAC doesn't prompt for it at Windows Startup.
Thank you for any advises, information, comments or solutions.
Does your application really need to start elevated? Or will it need to elevated access later when the user uses it to perform an action? If you can, drop the later admin task into a separate exe, allowing the main exe to start with no elevation - when you shellexecute the worker process later it will UAC on demand.
At install time, as you have noted, you have elevated the installer. If you want to run elevated code on subsequent runs, automatically, this is the point to install a service - which is what all those other apps you mentioned do.
You can't get around UAC for a process started in an interactive session. You could use a service running as a privileged user but you would be far better off finding a way to do whatever you do without requiring admin rights.
It's not possible for a program to run elevated without prompting. What you want to do is factor those portions of your application that need elevation into a windows service that runs as system. Then your autostarting application can make remoting calls to the service to delgate those activities that the user can't do without elevating.
Not done it but I found this article Selectively disable UAC for your trusted Vista applications that says use 'Application Compatibility Toolkit' from microsoft.
The Compatibility Administrator allows you to create a database of
compatibility fixes that will allow you to run certain applications
without an accompanying UAC.
Run the Compatibility Administrator as admin
select a new database template
Click the Fix button on the toolbar. When you see the Create New Application Fix wizard ... enter details about your app
Select a Compatibility Level
Select RunAsInvoker as the fix
It seems that the last one
Selecting the RunAsInvoker option will allow the application to launch
without requiring the UAC prompt.
Should do what you want provided that the invoker is admin and I think you can do this at start up using the scheduler : Create Administrator Mode Shortcuts Without UAC Prompts in Windows 7 or Vista
As you can see it runs your app in the compatibility mode which may or may not be acceptable for you.
I have an app that normal users need to be able to run, but requires administrator privileges to actually function.
I tried to make the shortcut that my users run it with "Run as administrator" but this just causes a UAC prompt whenever they try to run the app.
Is there any way to elevate privileges programatically, without my users needing to go through a UAC prompt and/or knowing an administrator password? From a security standpoint, I understand that most applications shouldn't be allowed to do this, so I'm hoping there is some way to do it if I can provide a valid username/password pair, or something.
The app is written in C#, so a fully managed solution would be preferred, but p/Invoke Black Magic (or even writing an MC++ Wrapper Which We Do Not Speak About) would be more acceptable than disabling UAC entirely.
Generally this problem solved by installing a Windows Service which runs as SYSTEM or an admin account. Then your application can request the privileged action from this service.
Obviously to not pose a security threat ensure that your service can't run arbitrary code or something which might leave the all users vulnerable to privilege escalation attacks.
Winpcap and most of the other sniffing applications use a similar design to give sniffing access to unprivileged users.
Actually, why don't you just create a Task Schedule which runs the app with elevated privileges? As long as you setup the Task under elevation, it will not prompts you for a UAC when it is auto-run during reboot or whatever your trigger is.
Just make sure you set level=requireElevation in your manifest file, and task scheduler will run your app with admin rights without prompting your user for admin rights, as this had already been established when you setup the task with admin privileges.
It's not possible. You cannot decide to suppress UAC prompt.
You have to ask yourself:
What would happen on Windows XP?
The user is a standard user on Windows XP, and the application "needs" to run as an administrator. Are you:
going to refuse to run?
going to crash on startup?
going to show the user access denied error messages?
If the user is simply not allowed to run the application as a standard user on Windows XP, then UAC is your friend: it tells the user that they have to be an administrator.
And it even offers to let them (temporarily) gain administrative privileges.
But you have to ask yourself:
What would happen on Windows Vista?
In order to elevate, the user will need someone from IT to walk from three buildings over, so they can type in their credentials "over the shoulder". Perhaps you can make the user's life easier. Let 99.9% of the application run, and split off that 0.01% to an "administrative" module.