Here's a nice little tutorial explaining how to enable or disable startup programs in Windows 10 when running under a limited account, including registry hacks and the SuRun mechanism. Enjoy. https://www.dedoimedo.com/computers/windows-10-limited-acc-startup-programs.html Cheers, Mrk
@Mrkvonic Great article and such a gem of a tool. I noticed that the latest stable release is quite old now, however, it is good to see many recent commits to source code with lots of great features and fixes coming. Spoiler: Upcoming Features / Recent Commits ToDo: --------------------- * Handle \??\C:\Windows\System32\conhost.exe* make Tray Windows for automagically started apps configurable * Hooks must directly write to Service pipe * on Win x64 detect x32 Executables on x64 hook (ShellExecute32->WoW->CreateProcess64) * On ShellExec/IAT-Hook: Create Process suspended! Hooks must resume process. * Create Inline Hook instead of IAT-Hook * GUI for SwitchToUser * Create a "Default" SuRunner for users that are not in "SuRunners" * MAP network drives * Checksums for "Always Yes" programs * use IContextMenu2/IContextMenu to implement an Icon/Popup menu * Console SuRun support * LOG-File for SuRun activity To be done in future: --------------------- * Use Radio-Buttons for (normal/elevated) Auto-Magic * Hide/Show all context menu entries consistently * make all context menu entries dynamically with ShellExt (E.g.: msi with popup-menu) Deferred Whishlist: --------------------- * icons for SuRuns context menu entries * Intercept CreateProcessAsUser in services and check for programs started with limited rights that need to be started as admin ------------------------------------------------------------------------------ SuRun Changes: ------------------------------------------------------------------------------ SuRun 1.2.1.3b3 - 2017-08-20 ---------------------------- * NEW: SuRun detects renamed computer and imports user's settings * FIX: User Bitmaps for Domain Users were not shown SuRun 1.2.1.3b2 - 2017-08-09 ---------------------------- * NEW: Moderated Restricted Surunners. ("User can only run predefined programs with elevated rights") If a restricted SuRunner tries to run a non validated Programm with elevated rights, SuRun will now ask for Administrator credentials to launch the program elevated in the user's context. * FIX: Fixed Spanish Resources SuRun 1.2.1.3b1 - 2017-03-11 ---------------------------- * NEW: SuRun Executables are digitally signed * CHG: Changed SuRun's Context Menu Strings from "<...>" to "SuRun: <...>" * FIX: Members of "Power Users" and "Backup Opeators" could not use SuRun * FIX: Bug in IAT-Hooks made Internet Explorer Crash on Windows 10 The SuRun Changes, in particular, is a nice ChangeLog for what is coming up in the next release. I've tried building this from the most recent source code but far too many errors to compile. It would be great if the developer would share binaries for us to test those recent betas.
None of that for me. I limit the Administrator account with SRP. That prevents dangerous changes from being made to the system while at the same time still allowing me to drop restrictions temporarily when necessary.
I didn't know that you can use SRP to prevent dangerous changes from being made to system. I thought it can be used only to control what can execute. Personally I use LUA to prevent dangerous changes to my system. Can you share your SRP configuration and rules?
I use SSRP. Simple Software Restriction Policy. I only unlock the policy for software upgrades and to install new programs. I have edited the shipped software policy ini.file to allow certain programs to run from locations normally disallowed by the SRP.
I doubt that this will offer a level of protection you would get if you applied an approach as suggested by Mechbgon which is still the way to go, IMHO. With your approach you still have to rely on UAC if an application which you allow in SRP tries to write in a folder/registry branch where admin rights are required. As often discussed here, UAC is not a security boundary (although setting it to max improves the situation) whereas a limited user account is: You don't have write permission to critical folders/registry branches. Period. Hence, the combination of a LUA with SRP is ideal. Besides, I don't see any reason why one should not implement Mechbgon's advice: I haven't used my admin account in ages as I've been able to perform everything (without any exception I can remember) in my LUA with UAC. Back to the topic: What advantages does SuRun offer over UAC in Windows 10? I guess it was certainly very useful in Windows XP/2000 - but in W10? Perhaps I'm missing something ...
Yes but SSRP probably won't block "dangerous changes made to system". It will only block execution of non-whitelisted applications. That's not the same as preventing dangerous changes from being made to the system, as you said it. LUA OTOH can.
Summerheat, it offers the ability to execute some apps/processes you cannot do with the standard admin privilege elevation prompt. Like the example above. You can also whitelist apps for auto-elevation, and a few other neat tricks. Mrk
SRP blocks execution of executables from locations from which they shouldn't run. I do have to whitelist applications from there that do need to be allowed to run. That why it blocks ransomware because of where its dropped to. And if it can't run, it can't encrypt Windows folders and their contents.
Yes that's true but ransomware is only one part of dangerous changes that can happen to system. If whitelisted app is abused it can do harm to your system also. And SRP won't protect you here (application is whitelisted and SRP doesn't care what it will do once it's run). Dangerous changes to system don't come only from new (unknown) executables, but from known (whitelisted) also. LUA can help you there. SRP and LUA offer different kind of protection. One doesn't substitute the other but they rather complement each other.
I could never understand why people won't run as a Standard User the majority of the time. Only when I've changed permissions on directories have I needed to run as Administrator. Default-deny is a great enhancement for sure to an LUA. It can get tricky in some cases, however, when you come across user-space executables or a DLL that require a lengthy Path rule such as: Code: %OSDRIVE%\USERS\*\APPDATA\ROAMING\MOZILLA\FIREFOX\PROFILES\*.DEFAULT\EXTENSIONS\SUPPORT@LASTPASS.COM\DATA\NPLASTPASS64.DLL A Hash rule is a bit more secure but then it needs updating whenever the DLL changes via an update. EDIT ...even better, I was able to create a Publisher rule off the DLL Code: NPLASTPASS.DLL, version 4.1.0.0 and above, in NPLASTPASS, from O=LASTPASS (MARVASOL INC), L=FAIRFAX, S=VA, C=US
