While set as Basic user in gpedit.msc, I get Event 866: Access to C:\Program Files (x86)\SeaMonkey\seamonkey.exe has been restricted by your Administrator by location with policy rule {35eccb52-9612-484f-9abd-939ffef81b69} placed on path C:\Program Files (x86)\SeaMonkey\seamonkey.exe Everything else I put in (browsers, pdf readers, WMP etc) get identical message, just different {numbers} It works in XP for ages, but not in windows 7 (64-bit, Pro). What am I doing wrong? Kees once wrote instructions, which I can't find now I have several child .exe files in Kingsoft office I want totally blocked and I thought I could try via gpedit, but if I can't get the simple things going, I'm lost. I run with admin rights (yes, I know it's a sin), and UAC at max. Edited: added underlined words
I am not sure how running with Admin Rights will impede the following, or if I am explaining what you actually want. It has been 1-2 months since I moved over to Limited User Account. If you are talking SRP as in the little application called SRP... then try this, might work... In your softwarepolicy.ini file, scroll down towards the end and look for a heading called "[Disallowed]". If you see an entry there for seamonkey.exe, and it does not have "; " as a prefix, then add it. Save the ini file, lock SRP up and try and run the browser again. Do the same for the other applications you mentioned. You might also want to have a look at "[LimitedApps]", for extra restrictions. From my experience, running IE without ; doesn't work, running Media Player Classic without ; doesn't work either. It'll come down to trial and error. If you are talking SRP via Group Policy (right click, run as Admin - regardless if you run with Admin Rights or not)... then try this, might work... Have a look at http://www.mechbgon.com/srp/ for full description of the following... Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Software Restriction Policies > Security Levels - Check if Disallowed is the default by right clicking Disallowed and confirming that "Set as Default" is not visible in context menu... Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Software Restriction Policies > Additional Rules - Add this entry, if not present: "C:\Program Files (x86)" in this section, with Type = Path and Security Level = Unrestricted (I think these settings commit in real time, so a reboot might not be needed) - Do the above for the child processes you want blocked, but for Security Level, chose Disallowed Hope the above helps in a way...
Hi, act8192 As Marzametal explained you have two Program Folders when on 64 bits. The 32 bits applications are stored in C:\Program Files (x86) and 64 bits applications are stored in C:\Program Files Make a picture of your the additional rules and post it. Then tell what you want to achieve (what to allow and what to block) regards Kees
I did what Marzametal described in the second half of the post. But I didn't do this part. Won't I block everything? Scares me. "Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Software Restriction Policies > Security Levels - Check if Disallowed is the default by right clicking Disallowed and confirming that "Set as Default" is not visible in context menu..." I'll go and read that link... Ouch, I did read it earlier. Too confusing for me Kees, I just want to drop rights on the browsers, as I did on XP. I may be wrong with * wildcards, so can you also help on that syntax please. Here was my attempt which so far failed. (It's a good thing they have Export, because picking those paths is a major PITA). As in the picture, I want few things as Basic user and few totally blocked, especially those Kingsoft pests. GWX doesn't bother me, it's blocked other ways. Darn, there's export but no import
Don't know about Seamonkey but you don't need *.exe to set those rules. If you create rules for folder everything in that folder and subfolders will be allowed. I also replace default registry rules with path rules as registry rules sometimes wouldn't work for some apps. EDIT: if you'll replace registry rules with path rules, add path rules BEFORE you remove registry rules.
@act8192 From Vista to Windows 7 Microsoft made some changes to Software Restriction Policy (SRP) In XP (and Vista): Basic User is allowed to run, but the executable runs in LUA-box (drop-rights from admin to limited user=basic user) Due to the introduction integrity levels (IL) and User Account Control (UAC), all process started with medium IL (same rights as basic user). With Vista these IL could be set to mandatory (in all Vista versions using ICACLS). Because this abiltity to make an IL mandatory overlapped with SRP, Microsoft decided to the basic user implementation in SRP In Windows 7: Basic User is same as Disallowed (deny execution), with the option to RUN AS ADMINISTRATOR. When you had specified in ENFORCEMENT that SRP applied to "All users except local administrators". See picture So the basic user rules of XP turned into Disallowed rules in Windows 7. Remove the BASIC USER rules
Man if any of you could give a guide for Windows 10 64-bit systems, SRP, DEP and etc. and similar built-in protection guide.
I wouldn't even know where to begin for W10. I haven't even run W8 yet... lol Cheers @ @Windows_Security for the info change from WV to W7. Would you happen to know if any changes were made to SRP from W7 to W8 to W10?
Yep, when you set default level as basic user AND set a program to basic user this would run from taskbar and start menu only. For some programs you had to use a shortcut to make it work (e.g. Outlook) and some (chrome based) did not work when running them as basic user (chrome does not seem to work when using drop rights in admin account). So this (double) Basic user Windows7 feature could be a workaround for your problem. This undocumented feature was removed in Windows 8. In Windows 8 it was still possible to use a registry tweak to run MSI as Admin (see Symantec) when setting default level as basic user and setting SRP for all users except admins. In the November Windows 10 update this does not seem to work anymore. So it seems that Microsoft is still improving on SRP, while having introduced a better mechansm (AppLocker). But as always with Microsoft you need to be clear-sighted to understand their strategy. Example1: hey let's force everyone to tiled interface, also the people working on desktops (W8 ), heylook at our latest OS it has a fully functional startbutton again (W10) and facilitates two modes: tablet and desktop. Or even worst example 2: hey lets buy Nokia a phone company which missed the smartphone trend to enter the smartphone market. Hey an even better idea, let's produce smartphone's under our own brand and sell Nokia (writing off 7.6 Billion U$)
Kees, thank you very much for your usual thorough explanation. I did what you said. Thanks for the screenshots too. Related issue: ProcessExplorer trouble. It's not installed in Programs. It's in c:\MyUtilities. I've always been annoyed that I have to answer UAC alert even when I click RunAs admin. It's a nuisance when speed is of essence. So I added it to SRP as unrestricted. I can't run it from a shortcut I have. I can't run it clicking on the .exe file. The screen, in both trials, says Reason is that PE loads \procexp64.exe into \temp which is blocked, except for admins. But, I have admin rights. Arrghh. It has to do with those two admin layers, doesn't it? And it looks like SRP takes precedence over UAC, right?
The workaround for this... might annoy you somewhat is to reverse changes made, then run Process Explorer again. When it is running, navigate to the temp directory, copy procexp64.exe to another directory, and then link the desktop shortcut to "procexp64.exe". This way, you won't ever encounter a temp directory restriction for Process Explorer ever again. I copied mine to a Program Files folder that I use for little tweaking apps. The SRP app, when locked, didn't allow Process Explorer to run, even though I added a custom path rule for temp directory referencing "procexp64.exe". It wasn't until I unlocked the SRP app, that Process Explorer was allowed to successfully load. This is making me think that whatever changes I made to Group Policy SRP are for crap. EDIT: I ended up re-installing "Secure Folders" to set Temp directories to "no execution".
Marzametal, I moved procexp64.exe to c:\MyUtilities\ProcessExplorer directory. Cute idea And changed the shortcut path. No windows complaints. But the effect is nil. If I just run it, it runs as basic user. If I RunAs admin, UAC pops up. Exactly as it always was before. I suspect my two favorite shortcuts, PE and TCPview are doomed because of all the things they do, and superAdmin really has to watch it. I don't have SRP locked. It's beyond my skill level. I'm just trying to follow some of good ideas Kees writes about, hit snags, and bang my head against the wall. Or come here. Thanks for helping me.
What an idiot I am... I tried to reply to your post, but couldn't get it working. I finally realised that I was pressing Report instead of Reply. What a dip! Anyways, might have found another cute idea. I am not sure if it'll work, but hey... give it a shot. I remember CCleaner made an entry in Scheduled Tasks which bypasses UAC. The same approach might work for Process Explorer? I have included screenshots of the Scheduled Task. See if you can replicate them. Spoiler Spoiler Spoiler Spoiler Spoiler
Soon after I got this laptop and tried to deal with PE, I saw the CCleaner trick. I tried it for PE. Didn't work then. I will retry tomorrow. Perhaps I skipped something. I started this thread because of Kingsoft office nuisance. It's all been tamed by SRP. Outpost HIPS still logs that those processes were launched/launching, but event log and no more scheduling prove they did nothing.
Don't need Kingsoft help, as I wrote, it works great. Totally suppressed. Process explorer issue also solved With Procexp64 already permanent in MyUtilities, I made the task just like CCleaner. After some fighting with windows, I removed the Argument in Actions and it finally worked when I clicked Run in task scheduler. Then I made a shortcut to that task with /run and /tn parameters, and it, too, runs great with no UAC prompt after 2-3 sec delay.
