SRP method

I want to hear from anyone who has used this method and how it has worked for them.

http://www.mechbgon.com/srp/

 

I use it on my Win7 Pro 64-bit system and was using it on XP Pro before that.

It works nicely as a sort of poor man's anti-executable. I like the control it gives you in that executables can not run outside of Windows and Program Files folders unless otherwise specified.

 

I used it a while back on an XP system in conjunction with LUA and it seemed pretty good. I understand that it's not 100% bulletproof and has been picked apart a bit by those who understand the details much more than I. But I think that along with LUA it can be an effective strategy. I haven't tried SRP yet on my Win 7 x64 system as it seems to be someone of a sticky proposition, I don't have Pro or Ultimate, just Home Premium.

 

@Reimer

Are you using it a long with LUA and SuRun? If so, any problems

@Kerodo

Did you have any problems running your apps? Did you use SuRun with it?

My goal is to use LUA, SRP with SuRun.

 

SRP is important part of my security setup on Windows 7 Ultimate x64. It is working very well. Follow the guide and deny everything else. You are good to go.

 

That's what I use on my machines, works great. I haven't had any real-time malware scanners running in ages and everything is still clean.

SuRun makes a limited account much easier, I would definitely install it. What OS do you use? If you have Windows 7 you need the latest beta of SuRun, which can be downloaded from links in the forum.

 

@Boyfriend, Johnny123

Thanks for the positive feedback. I'm using Vista Ultimate 32bit.

Oh, so they are making SuRun for windows 7, that's good to hear.

When I first ran across the link in first post I thought that was a neat setup and I wouldn't have to invest more money in security software; sounds like a winner to me. Some of the simplest things work best.

I need to nuke this set of windows and when I reinstall I will set this up.

 

With Vista you can use the 1.2.0.8 version. Apparently Windows 7 does a few things differently which are adressed in the beta version.

It is a neat setup and it works! No updates required, no blue screens, no system drag. I have Avira installed on one system and Avast on the other without the real-time guards so that I can scan files I download. I do a system scan every once in a while to turn off the dire warnings of not having done a scan, but they never find anything.

If you're re-installing that's a good time to set it up. This helps to avoid ownership problems that might occur if you switch an existing account to LUA. Install all the drivers and printers or whatever and then make yourself a new limited account. Then install SuRun in the admin account and add your LUA to the SuRunners group. Then you can install all your apps. You can do this in the LUA using SuRun. Nice part about this is that you are still in your user environment, only the installer process is running with elevated privileges.

 

I was worried about installing software and it running properly in LUA, but you rest my fears on that.

 

Nope, no problems running apps. I didn't use SuRun....

 

Be aware that there are some apps that don't work properly in a LUA. Games are notorious for this and there are some security (!) apps that don't work right as LUA. Threatfire and Rising AV come to mind. They won't update unless you're running as admin. A security app that requires you to run as admin is an oxymoron. Some developers are apparently still in Win 9x mode.

You can ask around here and I'm sure people will give some tips on what works well with a LUA. IrfanView is a good example of an app that's done right. It asks if you want to install it for all users and you can select to install the .ini file to your user profile instead of the program folder. Some burning apps (like Ashampoo) will say you have no optical drives if you don't start it as admin. I use a burner called ONES, and it doesn't have any problems at all running in LUA. I'm sure Windchild, tlu and Lucy can give you some good suggestions here.

Some apps don't work in a LUA because they do things you don't have privileges to do, which makes sense. Defraggers come to mind and things like Tuneup Utilities. Image for Windows also has to run as admin. This is when SuRun comes in handy. Just right click and select run as administrator. Give it a go, it doesn't take long to get used to it.

 

Johnny, thanks for all the good info. I'm in preparation mode now (make sure I have everything I need and backing up certain things) before the installation.

I have one question for you. I forgot there is two Admin accounts, one is local computer privliges and then there is the real Admin account that is disabled by default. Which did you use with SuRun?

 

Using SuRun latest beta in Win7 for a few days has been a pleasant experience so far

 

Leave the account you make during the installation as it is. Before you do anything else, make a limited account in addition to this. Let's say they're called admin and user. Log on to admin, install SuRun and then there is some configuration to do with that. On the second tab, SuRunners Group, you need to add "user" to the group.

On the first tab there's a button at the bottom to click with recommended settings for home users. If you don't feel like playing with it, just click that. I would recommend checking to show advanced features because there are other things you may want to set up, like allowing the LUA to set the time, change the SuRun settings, whether or not a password is required, etc. For example, I have it set to not ask for a password because I'm too lazy to type that in all the time and my admin account doesn't have a password to start with. This may sound weird, but if you can control physical access to the computer, it's actually safer to have no password for the admin account. To log on to an account without a password you have to be actually using that computer, you can't log on remotely. Got that tip from Aaron Margosis' blog. He's the MS guy that wrote MakeMeAdmin.

 

Have you left UAC turned on? From looking in the beta forum it seems like there were some problems with UAC picking things off before SuRun got a chance to do anything. I would guess that you might be able to just turn off UAC, but I'm not sure about this.

 

Right, and I should clarify although a pleasant experience, not a perfect one, either, because I did encounter one issue where I was experimenting with Secunia PSI starting with Windows via automaigically with SuRun, no password, but UAC did indeed intercept and interfere. For me this is at least a minor issue because I don't really want PSI starting with Windows, but at least whenever I want to run it, I can do so with a right-click run as Administrator with SuRun context menu selection and avoid typing the normally required UAC credentials. I think turning off UAC, as you suggest, would likely resolve the issue, but I didn't bother trying because I don't want it disabled.

 

I disable the option "Try to detect if unknown applications need to start with elevated rights". If I want to start something elevated I just right click and select "start as administrator". I enable UAC because it virtualizes write attempts to program files directory.

 

I don't quite understand this. In a limited account you don't have write privileges in that directory, seems a bit redundant. If you start an app as administrator and it writes to %Program Files% and UAC "virtualizes" it, does that mean it's gone when you re-boot? Inquiring minds want to know

 

It isn't redundant, the visualization works regardless of elevation. Write attempts get redirected to C:\Users\<user>\AppData\Local\VirtualStore, those files aren't gone after reboot.

 

I'm feeling a bit dense because I don't see the point. In a LUA if a malware tries to write to Program Files it can't because there are no write privileges for that directory. So what's the advantage of having the malware written to this VirtualStore directory rather than not being written at all?

What do you do when you want something written to Program Files, like when you update an application? Everything that's been written to Program Files lands in this VirtualStore? I just don't get it, please enlighten me.

 

Some info on UAC:

-http://technet.microsoft.com/en-us/library/dd835548(WS.10).aspx

 

It's for compatibility not security. As the link provided by wat0114 indicates, virtualization is "a short-term fix and not a long-term solution".

There are two types of apps that virtualization makes them compatible with Win 7.

1) An administrative app that needs to write to program files or other protected areas but isn't UAC compliant.
2) A normal app that doesn't really need to write to program files and could instead write to ProgramData or user profile but is either old or its developer didn't care about Win 7 compatibility.

If a program you use updates its files to its program folder then yes it will be redirected to VirtualStore.

FF Dictionary...

 

This visrtualization aspect of UAC is an interesting (to me, anyway) topic. In the link under UAC Architecture (I've underlined some points):

This last point puzzles me. i have no idea what it means

But it does seem execution level does matter where virtualization is concerned, or am I misunderstanding something?

 

The term virtualization is somewhat ambiguous in this situation I believe. Most of us are used to thinking of a virtual machine like vmBox or vmWare. This to me is the pinnacle of virtulization - a complete virtual computer running its own OS on your OS. Simply boggles the mind

This type of virtualization is more like Sandboxie. Sandboxie creates a physical location for what it houses in c:\sandbox. This M$ virtualization is like that, the physical files are on the drive for the system to see. M$ differs from Sandboxie though in that Sandboxie keeps the OS from "interacting" with the sandboxes and regstries unless the user means to interact with them. M$ keeps everything on the OS. The registry values are simply in a special "area" of the registry. The files, you can access them just like normal.

A manifest is a piece of code that a program has in it. Maybe you could think of it as a header or cover sheet. One thing it does to declare that the program needs administrator rights. UAC is built around this aspect. UAC "pops up" because it reads the manifest, finds whether the program needs admin rights, and if so, asks you for permission to elevate.

Older programs may not have a manifest, or the manifest just doesn't have the correct data for use with UAC. Of course maybe the programmer didn't want to incude a manifest, who knows. But what is M$ to do without one? UAC won't work because there is nothing to tell M$ whether the program will need admin rights. With no manifest, the program might start, but would be unable to do what its intended purpose was because it needed admin rights.

Remember, UAC is supposed to nag developers into coding things properly for user accounts rather than admin accounts. The "transitional" period is still here. M$ is still using UAC to allow time for developers to leave full admin modes and begin to work properly in user accounts. Of course not all programs are meant to do that, but many could if they were built differently.

M$ has a dilema. There are many older programs that must run as admin to work, because they write to HKLM or Program Files, areas that are off limits for users. If they wanted people to buy Vista, they had to make sure it worked with older programs. So, they came up with virtualization. All it means is that when a program is run, and the program tries to do something that a user cannot do, special areas are allocated for it to do them in, so that the program continues to work.

For example, if your program from 2002 keeps its profile in Program Files, when ran in Vista it will not be able to write there. The program might start, but be unable to save the settings. Virtualization allows the program to write to what it thinks is Program Files, and there for work properly. But in fact the writes are being redirected, via the virtualization, to an area that is meant for such purposes, but not the real Program Files. The same is true of the registry. A special area is kept aside so that the program works and thinks it is writing to HKLM, but in fact it is not.

Now imagine that you forced a program to start virtualized. What does that mean? Well, it means that if it were to write somewhere, it would be in a virtualized area. That only means that it is not writing to the real area. Does it mean the program can't modify a system critical file? It should, because it only thinks it is writing to the real location. I don't know all the details. I don't know how it handles certain aspects. For example, if you run a program virtualized, and then modify a system file (like autoexec.bat), does it create a copy in the virtual area, similar to how Sandboxie does it? Or does it just not save at all? Don't know.

I am only sharing that the virtualization comes about because M$ needs older programs to still run right now. They clearly state that this is a temporary fix. How temporary? LOL. Might be a long time. At some point they want thier OS to be 100% user mode like Linux is. All programs would need to be compliant with such a scheme or they won't work as intended. Can you imagine if they had done that starting with Vista or 7? How long would you have used it if much of the software you owned wouldn't work in LUA, and thus would be of no use to you unless you were full admin or wanted to RunAs all the time?

Sul.

 

Sully, very nicely explained Thanks!