PGS - Pretty Good Security

No bugs yet.. as far as i can tell anyways..Ive been interested in SRP now for awhile but never had the time to get in to it.PGS makes it easy and saves me the time and frustration. Thanks again.

 

Sully appears to have released a new beta version of Pretty Good Security for those who are interested. It's version 1103 found here...

http://mrwoojoo.com/PGS/PGS_index.htm

Later...

 

I was about to ask when a new one would come out, because the previous one ran out of date.

Thanks

 

Future betas will have some refining of the tool. I am currently working on a way to take ownership of objects, containers and registry keys, as well as create a flexible .ini style approach to cusomized rights on the same objects/containers/keys. Tlu gives an excellent way to do this, I am trying to automate it with some more flexibility for those who need some extra help in areas like that.

Feedback on your experience with PGS will mean possibly adding/modifying aspects of PGS. So far all has been pretty quiet, so either I did a good job on first release or it is not used often enough to warrant any fine tuning. Could be either or both, one would like to think anyway

As of now, until I find time to finish the peices I am currently working on, it will remain beta, and on the beginning of each month a new verion will be compiled. Well, same version, but the time restraint applies per month. If there is an actual change to the beta of any consequence, mods have already told me they could change the first post to give information of such things.

Basically, on the end of each month, I psuedo-force you to get a new version for it to continue to run. As I have said, this is so if there is a definite need to have a newer version because of a serious bug or something, peeps don't archive it (in a buggy state) and continue to use it with it's bug. You get the idea.

I think perhaps some 7 features might be forthcoming if I can gather a few extra hours from somewhere.

Sul.

 

Sully,
How about adding a simple Enable SRP selection just as you have a Disable SRP (or am I missing something).

Thank you for your work.

Later...

 

You might be missing something, but don't discount anything for sure. I believe you refer to the Automatic Setup TAB. Perhaps this title needs changed. Automatic setup was originally going to be an easy method for peeps who don't know as much to easily engage it. However, as things developed, I needed a way for PGS to change certain values, while ensuring other values were not incorrectly set.

You will note on the SRP Manager tab, you can manipulate the 2 primary options in SRP, apply to dll's or not, and whether to exclude admins or not. Secondary options are enabling a log file, enabling the 'Basic User' option and finally a way to modify the file extension list. What you do not see there is the option to change the default action (deny or allow).

In order to ensure proper functioning (especially for novice users), the Automatic Setup tab is the only place that default action value can be set. So, when you choose to setup as LUA or setup as Admin, the proper values are set. This engages either one or the other. The disable SRP simply makes the default to allow unrestricted, so no SRP takes place. Engaging SRP again can be done by either setup as LUA or setup as Admin.

Those who have used it, what say you. Is it simply enough to know you check the option for setup (LUA/Admin) and apply, or would it be better to include perhaps in the tray icon, on right click, maybe option for Engage as LUA, Engage as Admin or Disengage.

I am more than willing to modify PGS look and feel to what I can do. Syntax/grammer, navigation, labeling, anything peeps notice as confusing or incorrect, don't hesitate to mention.

Sul.

 

I haven't had ample time to play around with this. I have loaded this in a VM and it seems simple to use. I like the check-mark after completion of a task. I plan on giving PGS additional time this weekend. I really like what you have done, so .
Allen

 

Hi all, hi Sully,

I still have some problems to understand or use this SRP environment

I'm running Vista with the user created during installation, UAC is enabled.
AFAIK this user is an Administrator account. The UAC comes up before
executing task that needs a special attention - even in this administrator context.

How do you configure PGS in the above configuration, what settings do you enable/disable?
What "Path rules" do you use in PGS?

So far I've started with the automatic setting "Setup SRP...Administrator" ...

Most of my apps (VLC, Notepad++, Irfan, Firefox, Foxit Reader, Office ...) are installed on
drive D:
I only install security software like Kaspersky, KeyScrambler, Sandboxie... into the
default path "c:\Program Files".

 

The menu option File->Options->"Restart the shell" does not work on Vista.
A message box comes up and tells me that taskkill.exe was not found.
On my system it is found here: c:\Windows\System32\taskkill.exe

PGS 1.1.0.3

 

No offense meant - but as long as you are not even sure if you're using an admin account or not and you don't know how to find out you shouldn't bother about SRP and PGS. Some knowledge about Windows basics is necessary - otherwise you're most likely running into problems.

 

Where did I say I'm not sure? AFAIK does not mean "I don't know".

 

No, it means "as far as I know". That's closer to "I don't know" than to "I'm sure". But semantics aside, if you know what you're doing - fine!

 

The code for this function is simple: If taskkill.exe exists in sysdir, windir, or root, it sends it the msg to run with parameters /F /IM explorer.exe. If it is not found, it displays the msg box.

The code uses env variables, to account for any installations of the OS that are customized and not default. I could code them statically to c:\windows\system32, and probably most would be fine with that. But I tend to use env variables more for those cases when things are not default.

For now, can you copy taskkill.exe into c:\ and tell me the results. It should have found taskkill in your sysdir directory.

Can anyone with Vista confirm whether it works or not? I have removed vista in favor of 7 for some time now for testing.

Sul.

 

It is simple to understand, that you can only do 2 things with it. Either deny or restrict. From a LUA user, you would only deny or not. From admin, you would deny or restrict. The SRP option to allow only is needed if you wish to stop everything (default deny) and then allow specifics.

Yes, UAC asks about many things. You can turn it off, then that account will act like normal admin account does in XP, not asking everything with UAC all the time.

PGS is compliant with proper coding for UAC, meaning it requests admin rights. The prompts UAC to ask you, do you want to run it as admin. AFAIK it is working correctly in this respect in both Vista and 7, from my tests. So you don't really do anything in regards to UAC, it should already be done. All you need to do is allow it to elevate. If you kill UAC, it will run as admin and no prompts. If you run it from a LUA, it will always prompt for admin rights.

Path rules. I believe here you are referring to path rules in relation to UAC? There is nothing here that would be of benefit in an admin account that I can think of. If you were in a LUA, there should be a preset for *PGS*.exe. This is the one I would add, to ensure that PGS is alwasy in an allow path.

Setting up the SRP for administrator, like you have done, means all SRP rules apply to admins and users. Typically when you are using admin and SRP, you are denying some directory or file from executing. If an AV program creates popups, you could tell the file that displays those popups to not execute.

In the .ini file there are a number of files you could deny, such as format.com. It all depends on how often you need to use them. I tend to use the Restrict path rules the most. This allows me to start programs, such as a browser, with only a users rights instead of admin.

I have a feeling that most peeps here who use SRP are doing so from a LUA, and creating a default-deny policy with it, then opening holes to allowed files or directories.

Sul.

 

Sully,
I'm pretty much using it at the moment to deny any internet facing apps in the admin account from having full admin rights, along the lines of "Drop My Rights" approach. In a LUA account, how do you deny directories? Open up holes in said directories?
Allen

 

The syntax for SRP is as follows (these are path rules, I am using a Deny rule, Allow or Restricted work in the same manner) :

We will use notepad.exe as an example program and c:\test_dir as an example directory. In PGS I have used three different labels for path rules: Simple Name, Full Path and Env Var.

FILES:
Simple name rules need only the name of the .exe in question. No matter where the .exe lives, if it matches the name.exe, it will be denied.

Full path rules need a fully qualified path to the .exe. For example the rule c:\windows\notepad.exe will only stop notepad.exe if it is started from that directory. Copying notepad.exe to the desktop, and starting it from there will not engage the SRP rule because it is not in the correct path.

Env Var rules use Environment Variables. An Env Var is a nickname of sorts for directories or variables. For example, %windir% is a nickname for the windows directory, and %sysdir% is a nickname for the system directory. Since you can install windows in d: or a directory like windows could be winnt, the Env Var means you can reference a standardized value, and it does not matter what the real name is because the Env Var references the real name. Our notepad example could be used like this: %windir%\notepad.exe. Now no matter what your windows directory is named, this rule uses it and applies to the proper directory and notepad.exe

Env Var rules can also use registry keys. If you had a registry key such as HKLM\TestKey\Note_pad and the value of this key was c:\Windows\notepad.exe, the path rule would be %HKEY_LOCAL_MACHINE\TestKey\Note_pad%. You cannot use abbreviations like HKLM or HKCU, you must use the full key name. You may add suffixes and wildcards to registry values, but that is something you should explore on your own as I don't want to give information that is incorrect, as I don't use those often enough to fully understand thier impact yet.

DIRECTORIES:
When making directory path rules, you give the full path to the directory, such as c:\test_dir, or maybe c:\Documents and Settings\User\My Documents\test_dir. When using a directory, any executable the SRP is able to act upon is processed according to the rules of the directory. If c:\test_dir was a deny path rule, most executables within c:\test_dir would be denied.

These type of path rules can also apply to drives, like c:\ or d:\. Now the whole drive would be examined and executables denied.

WILDCARDS:
You can use the * and ? wildcards.

* means any match. So *notepad, note*, pad*.exe, noteped.* would all be ways to stop notepad.exe, but also anything matching. For example, *pad.exe would apply to both notepad.exe and wordpad.exe.

? is a little different. It applies to things in order, I believe. Suppose you had 3 directories, called c:\dir1, c:\dir2 and c:\dir3. You could use the ? wildcard like this c:\dir?, and it would match all 3. You can also use it like this, ?:\ and it will match a:\, b:\, c:\, etc.\

NETWORKS:
SRP can be used on UNC network paths, for example \\server\directory\notepad.exe. You can use wildcards here as well, such as \\server\*\notepad.exe. Suppose you had domain controllers, and you never know which would be elevated to primary for different outages etc. Suppose you name them \\domainC1 and \\domainC2. Your rule could use the ? wildcard like this \\domainC?\directory\notepad.exe or even \\domainC?\*\notepad.exe.

RULE PRECEDENCE:
When concerning Path Rules, the precedence is
Specific path rule first
Default rule second

This means, if you have a default rule of deny, and you start notepad.exe, if there is not specific rule to allow it, then the default deny takes place.

If you are admin, normally you have no default deny rule, you have default allow. In this case, notepad.exe is examined to see if it is denied, else it is allowed because the default is allow.

However, if you have differing path rules, the most specific one is the one that engages. Here is an example.

You should have a default path rule that says:
Allow - c:\windows\system32 and c:\program files
These 2 rules ensure you have access to these crucial areas.

Now suppose you created these rules:
Deny - notepad.exe
Allow - c:\windows\notepad.exe
Deny - c:\windows\system32\cmd.exe
Allow - cmd.exe

Which do you think will take precedence. It is easy to know, as the most specifically stated rule will. So in these examples, even though you denied notepad.exe, the Allow rule is very specific to allow c:\windows\notepad.exe. If notepad.exe were anywhere else, the Deny rule would effect it.

Likewise, because you Deny a specific path for cmd.exe, even though you allow it generically, the Deny rule is very specific, so it would come into play first if you started cmd.exe from c:\windows\system32.

Hopefully this gives you some idea of how to create your path rules.

Sul.

 

Sul,

Can I have a 'beta' without the time limit. It suites my needs at the moment and I have found no bugs which prevented it from working properly, so I would go in a personal release candidate state

Thanks

 

What more can I add?

+1?

 

#3 to the list. I've not seen any issues to date. I've used it on my main pc for about two weeks.
Allen

 

You are happy then with the state of the current beta? No problems to report then. If you are feeling it is in a state where it will pose no 'breakdowns', I have no problem with a non time restriction. The question is this then, for peeps who may not be as 'informed' of the project, is there any benefit at all to this 'forcing' them to get new version every month.

Please consider then, I am currently working on pieces to a larger puzzle that I hope to include with PGS, namely what TLU recommended in taking ownership of registry keys and objects/containers from the creator to the admin group. However, I am seeking an automatic and customizable method which will allow greater flexibility esp. for advanced users.

There are little things to fix, perhaps better help syntax and maybe some refining of labeling to reduce confusion. These are all non critical changes, so those who have used it and understand it probably won't even notice these things.

Also, when I can actually find time to install win 7 v7201, I have a feeling PGS will support win 7, and also having looked at AppLocker, there might also be a way to have PGS give some sort of interface to that as well. AppLocker, like SRP, has a clunky interface. I have not played with a version of 7 yet that allows AppLocker to even work correctly, so I am unsure on that yet.

With these things in mind is why I thought a month to month new build could help somone who might not know much of PGS to stay with a new/better version.

What say you.

Sul.

 

Sul,

I will look for new releases from time to time. Do not suffer from the artists disease, by fiddling to long with it. I think the take ownershiop is an interesting way to make PGS stronger than LUA by removing update rights of registry keys and files.

So I will use the current functionality and hop-on to the next one which offers take ownership (reduce ownership would be a better word

Regards Kees

 

Edit: Make the download again, reinstalled and it works.

 

As per requests, and since there have been no complaints of bugs, the time restraint has been removed and version 1 final is compiled and ready for download.

Follow the link in the first post.

Sul.

 

Running great on Vista64

See https://www.wilderssecurity.com/showpost.php?p=1519278&postcount=5296


Congrats Sul, something to be proud of


One additional request.

I would like an option to allow a few paths for a limited amount of time.

This brings along the following an extra data store with repeating occurenes in it, simular to the presets and the path rules
I would enter a few path entries which I wanted to allow temporarely (call them f.i. installation paths)

e.g. %USERPROFILE%\AppData\Local\Temp (the value of the TEM/TMP variable)
e.g. %USERPROFILE%\Downloads
e.g. C:\Program Files\Installation

Next I would right click a system tray icon and choose "install now" option, next I would get a screen with number of minutes with a default value of say 5 minutes, I could change the time and click change SRP

Thanks

 

I'm currently using this on my wife's laptop, on my desktop, and plan on using it on the kids desktop, . It's great!!! Thanks a bunch Sully!
Allen