PGS - Pretty Good Security

Even if you create a reg val for 131072 and put everything correct, it will not work.

For those who wish to be an admin, and take it on themselves to remain secure, I will be finding some solution for this issue. Unfortunately, there is not a way I can find for 7 to handle reducing privelages of specific files or directories in the same fashion as the SRP 'Basic User' options.

But, DMR does work in 7, and I for one am not going to be a user nor use UAC. This may not appeal to many, but for those who like it this way the next version of PGS will have some method that will work at least to make it more convenient to reduce rights per application or directory.

Sul.

 

Hello.

First of all - great program, but I have a questions.

It is not clear for me if it is going to work on windows 7 x32 Home Premium?. If not, is there any other way to have SRP under W7 HP?. I thinking about upgrading my winxp home and got to know .

Thank you all in advance.

Once again, great piece of software, Sully .

 

See this thread for what to do about SRP in win 7.
https://www.wilderssecurity.com/showthread.php?t=262686

The premise is the same as it was in Vista basically. PGS was not designed for use with win7, but it does work.

I have been using win7 and have not fully decided how it will effect PGS. Kees has provided us with some infos regarding some registry tweaks which will work thier way into PGS version 2. Providing PGS for win7 will be easy enough, but I wanted to address both Users and Admins with it, and frankly being an Admin in win7 with SRP really isn't as robust as it was in XP/Vista. I also have in mind to change the look of PGS, and might include significantly more features. The SRP feature is nice, but there are a lot of things in win7 that can be changed and I have been rolling around if I want one tool to do that or not.

Anyway, read that thread to see if it will do what you want. Maybe someone who uses the same version you are can tell us if it has worked for them.

Sul.

 

Sully, great tool, thanks.

I have a concern regarding the robustness of PGS. You mention in the descripton that if you modify something with PGS, then SRP(via secpol and gpedit) will continue to show the old rules. Is there any way to fix that? Even as a warning in SRP?

I'm just concerned that one day I might do something to bork PGS, and then if I go to SRP via gpedit, I wont see the true picture.

 

When you use the GP to create SRP rules, the registry values are written as normal, but also within the GP the definitions or pointers to those values are written.

If you create an SRP rule with GP, then you delete the GP rule, the registry is deleted with it.

If you create an SRP rule with GP, then delete the registry value, the GP shows the rule but it has not teeth anymore, it is null.

If you create an SRP rule with only a registry value (like PGS does) then the rule is valid but does not show up in the GP at all.

That is why I made PGS, because a) I could not find a way to manipulate the GP and b) home versions lack the GP. PGS main purpose is to have a way to show what those registry values do. Looking at them is a miserable experience, because you have to cross reference them around. It is much easier to use PGS which parses them out and references them together to show you in plain english what each one does.

If you ever do 'bork' your SRP, just restart in safe mode, and delete the SAFER registry key, then reboot. SRP is now back to normal. PGS is only a tool used to create/modify/manage the SAFER registry values, nothing more. Well, I guess it does give IMO a better method of managing it than the GP does. I use the import feature a lot, it is much quicker.

Sul.

EDIT: to answer your question, delete the items in the GP, regardless of if they exist in the registry. There is no other way I know of to manipulate the GP without gpedit or secpol.

 

Sully, that is a very well written post, may I suggest putting that post on the PGS page? With the line breaks and everything It also helps explain that the seeming incosistency between GP and PGS is just the incosistency between registry and GP.

BTW, what is the SAFER regisrty key?

When deleting the SAFER registry key; and rebooting; will a new SAFER key be created with the default values for SRP?

 

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers

The keys under 0 are for the denied rules.
The keys under 131072 are for the restricted rules.
The keys under 262144 are for the allowed rules.

There are some basic rules that should be in place. You can delete the 3 keys to get rid of all the rules. You can always use PGS, as it will put every value you need in place, because Home versions lacked any of those values at all.

Sul.

 

I used PGS to create SRP on Vista 32 HP machine running Admin. Worked like a dream but I decided to run this machine as a LUA.

I therefore deleted the SAFER keys in the Admin account created the LUA and ran PGS from the new account. I imported the allow rule for PGS, selected the Automatic Setup option for users rather than admin and then applied the defaults in the SRP manager. So far so good.

The SRP appears to work as advertised except I cannot open documents etc from my Data partition. An issue with loading dll's I think. If I move the file to C: everything works fine.

I had expected that as the exe's for the office applications etc were in the C\Programs folder they would be allowed by the SRP but now thinking I might need to set up specific rules for non-system partitions. Can someone confirm and give some advice on how to do that effectively?

Any help would be appreciated.

Thanks

 

I haven't used SRP as default deny much. I would assume that default deny is applied to all drives, so unless you make an exclusion, it is doing its job. If we think about the 2 default rules of allowing executions in program files and windows directories, and that we must make exclusions for anything else we want to run, it makes sense. I just don't know if other drives are also included in the default deny.

Sul.

 

Yes, if you tick "Exclude DLL's" under the SRP Manager tab you will be able to open the docs. If you don't want to weaken the SRP open Word first then browse to the doc. It should open that way.

 

Writing specific allow paths for the folders did not work, neither did allow paths for the specific applications. I guess SRP implemented this way with data on other partitions may not be possible without the changes suggested by jdd58.

Yes both worked, thanks, but I find one inconvenient given this machine is for users who just want to click and go and the other reduces security somewhat.

Mmmm, might go back to Admin, apply SRP in a more targeted way and use SBIE or similar to reduce the rights of risky programmes.

Thanks for the help guys.

 

I've been wrestling with this problem running as an LUA on a Vista 32 HP machine aswell...

I found I could restore the required functionality with a workaround. I added the following additional SRP rules for my data partition:

• Allow X:\ (where X: is the data partition)
• Deny X:\*.*
• Deny X:\DIR1 (where DIR1 is the first top level directory on partition)
• ...
• Deny X:\DIRn (where DIRn is the last top level directory on partition)

The first entry seems to be required to allow you to doubeclick on documents on the data paritition and launch the associated program. The rest of the rules re-enable "no program execution" from any part of the data partition.

Obviously, if you've a lot of top level directories on the data partition this workaround may be impractical. Also note that if you subsequently add a top level directory (or change the name of an existing top level directory), program execution will be allowed from that directory until you amend your rules set...

Exclude DLLs can remain unticked with this workaround.

 

Great! This has been a pain I haven't been able to figure out for a while now.
Thanks for the tip.

 

Ditto! Nice one sbseven

Can't say I'm sure why but it seems to work! I'll get my head round it to make sure I'm clear on it. No doubt it is what I need but I've never been very good at accepting things until I can get them through my thick skull! That might take some time on this one

Cheers

 

I'm not sure why it works either. It was something I discovered whilst playing around....

It seems strange that by allowing the data partition root, you enable the DLLs of an allowed system partition program to load properly under full SRP (exclude DLLs unchecked) when the program is launched via a file association within explorer.exe.

Is this behaviour specific to just Vista? Or maybe just when using this "registry hack" on Vista HP? Anyone got any thoughts on what's going on here?

Also, has anyone got any observations on whether this workaround is "secure" (excluding the issues with creating new / renaming existing top level directories)? What about write/execute permissions on the hidden $RECYCLE.BIN?