SBIE troubles with SRP !

[Ashanta]

I'm trying to combo SBIE and SRP, but SBIE don't work well under my standard user account (with Vita 32). It can't recover any files and any favorites.

I've just noticed that when launching SBIE from the system tray from my Standard User Account, it work for recovering files and favorites, but it doesn't work directly from my dekstop shorcut. Why ?

I've noticed that some others programs like Process Explorer, Autoruns (Systernals) , AdslTV and some others, don't launch and the window is freezing. Even with the Task Manager I can't close the freezing window. How to do it ? Any solution for that ? PE and Autoruns are in my SD's exclude list.


I followed the recommended settings from Mechbgon (I'm under Vista Business 32 bits) here : http://www.mechbgon.com/srp/

I add 2 additional rules for my firewall OP Pro, Sandboxie and Malwarebytes, all of three, are on F: drive under Program Files. Programs which are in the 'Additional rules' on the SRP, are they secure anyway ?

Who can help me to fix this issue ?

PS:SBIE and SD were working well with no troubles with recovering files, before executing SRP.

[pbw3]

Hi Ashanta,

I have no problems at all with SBIE and SRP, under Vista 32 Business SP1, and on a Standard User account..

The main difference with my set-up is that I keep all my programs under C:\Programs (and my data on other drives), hence I do not need to add any other program rules. Hence, my SRP set up is exactly as per Mechbgon (except that I switched off dll checking because of a problem with Excel that I didn't then have time to look at properly).

So not sure otherwise why SRP is making a difference specifically for you, or if this helps at all..!?

Do seem to recall someone else on here having a problem installing under other drives with SRP, and / or suggesting not a good idea, but I have a hopeless memory, so don't quote me on that - best to do a search..

It might have been here:

http://www.wilderssecurity.com/showt...=200772&page=9

around post 203+, or perhaps someone else can give you something more authoritative on that issue, if it is that causing the problem..??

Peter

[Sully]

Originally Posted by Ashanta

I'm trying to combo SBIE and SRP, but SBIE don't work well under my standard user account (with Vita 32). It can't recover any files and any favorites.

When SBIE starts as a service, does it start as System or User? As system, SBIE would have rights to create/modify many things, as User, only your user profile data. Without SRP Users could do this no problem. Disable SRP and the problem goes away? Enable and it exists again? Some rule then causes this I would guess.

I've just noticed that when launching SBIE from the system tray from my Standard User Account, it work for recovering files and favorites, but it doesn't work directly from my dekstop shorcut. Why ?

Again, this questions what the SBIE service has for rights. Is it system or user? Perhaps the reason the difference is seen would be that when using the icon, the service is starting the program (like Firefox) and the program inherits the rights of the service (which is system from what I have seen of the SBIE service). But when you start FF, SBIE picks it up, but FF has no parent (other than explorer) calling it so it inherits the rights of the user. Does that make sense, it does to me as a quick guess.

I've noticed that some others programs like Process Explorer, Autoruns (Systernals) , AdslTV and some others, don't launch and the window is freezing. Even with the Task Manager I can't close the freezing window. How to do it ? Any solution for that ? PE and Autoruns are in my SD's exclude list.

SD exclude will have nothing to do with this. SD exclude is simply saying 'do not delete here on reboot'. SD itself from my usage, has shown no issues with SBIE either. You may have an SRP that is having a rule too restrictive, or you have non default locations that need exceptions in SRP. If you remove SRP, does PE or AU run normally? Then enable SRP and they fail. Now it comes down to needing to remove or add a rule, or fiddle with the options. Seems straight enough, as Mech's webblog is not overly complicated with making SRP rules it should not take long to figure it out.

I followed the recommended settings from Mechbgon (I'm under Vista Business 32 bits) here : http://www.mechbgon.com/srp/

I add 2 additional rules for my firewall OP Pro, Sandboxie and Malwarebytes, all of three, are on F: drive under Program Files. Programs which are in the 'Additional rules' on the SRP, are they secure anyway ?

Who can help me to fix this issue ?

PS:SBIE and SD were working well with no troubles with recovering files, before executing SRP.

When SRP is engaged in this fashion in a user environment, you have a default deny situation. You must open holes for areas that you do not wish to default deny. If you have followed that website correctly, your normal stuff should be taken into account. Any and all of your custom directories must have a rule made in SRP else they fall under default deny.

The puzzling piece here is why would SBIE service, which starts each sandboxe (I think), be somehow restricted from writing/modifying your user profile areas. Perhaps you mean recover to those areas? Maybe a test, to use SBIE to have direct access to the profile areas, and see if it is different. SBIE should create a virtual directory exactly like the real one in c:\Sandbox\xx\xx so you can see if it is located there, and add or remove things and then use recover to manually play with it.

As for why PE and AU is locking, perhaps you could elevate them with RunAs to Admin and see if they still do it. Perhaps there is a dll that is needed, thus the include dll option may help.

Tlu or Lucy use LUA enough with SRP they probably know more than I.

Sul.

[Ashanta]

Originally Posted by Sully

When SBIE starts as a service, does it start as System or User?

I don't know, I can tell you that the owner is Admin and I'm running from my SUA (standard user account).

Originally Posted by Sully

Disable SRP and the problem goes away?

YES, the problem goes away.

Originally Posted by Sully

Enable and it exists again?

Yes, indeed.

Originally Posted by Sully

If you remove SRP, does PE or AU run normally?

Yes, it works !

Originally Posted by Sully

Then enable SRP and they fail.

Yes again !

Originally Posted by Sully

Now it comes down to needing to remove or add a rule, or fiddle with the options.

What really does when Adding a Rule, just give access to system file ? AR don't open a hole on the program for beeing pick up by malware or rootkit ?

Originally Posted by Sully

The puzzling piece here is why would SBIE service, which starts each sandboxe (I think), be somehow restricted from writing/modifying your user profile areas. Perhaps you mean recover to those areas? Maybe a test, to use SBIE to have direct access to the profile areas, and see if it is different.

I already did with a direct access but nothing changes.

Originally Posted by Sully

SBIE should create a virtual directory exactly like the real one in c:\Sandbox\xx\xx so you can see if it is located there, and add or remove things and then use recover to manually play with it.

Yes, I noticed that the file or favorite was in the Sandbox folder, but SB couldn't recover from SB Control.

I already sent a PM to Lucy, in french, but not yet received an answer.

[Lucy]

Ashanta,

don't use a different partition for your programs. Otherwise you may experiment anomalies such the ones you encounter, because SRP has not been designed to handle this.

Rather uninstall and re-install your programs on your system partition after having switched off SRP.

When you re-enable SRP, be always careful to start from default rules and then make then more complex at your convenience.

It should do the trick.

[Ashanta]

Originally Posted by Lucy

Ashanta,

don't use a different partition for your programs. Otherwise you may experiment anomalies such the ones you encounter, because SRP has not been designed to handle this.

Rather uninstall and re-install your programs on your system partition after having switched off SRP.

When you re-enable SRP, be always careful to start from default rules and then make then more complex at your convenience.

It should do the trick.

Thanks for your advise Lucy, but in my case, it will be impossible, I have 94 programs installed on my computer.

I need others solutions.

[Lucy]

I leave it up to you.

Security doesn't come afterwards, when everything has been set up. It is a process that has to be taken into account from the set up of your machine.

If you need other solutions, so maybe LUA + Sbie is already great.

[Ashanta]

I'd like also to have tlu's point of view about problems I met with SBIE and others programs, thanks.

[Ashanta]

What I'm not understand is why I have to c:\Program Files\, c:\Dekstop, f:\Program Files with my SUA and SRP and UAC activated.

Nevertheless, I can't access to images, videos, music, pdf files neither with my SUA and Admin account. In my SRP settings, under 'designed files type' I don't have any music, video,images and pdf extension.

It's really strange SRP on my computer !

Could your remind me the folders protected by default deny SRP and registry entries for Vista Business ?

[Sully]

I don't use LUA or Vista much. I use XP and Admin mostly, with some testing in 7. I use SRP to restrict programs to Basic User, or deny them. SRP works perfectly for me. It does not matter what drive/path I use it works as expected. Using under LUA with a default-deny approach is much different.

Here is a good technet article on SRP.

http://technet.microsoft.com/en-us/l.../bb457006.aspx

Sul.

[pbw3]

Originally Posted by Ashanta

What I'm not understand is why I have to c:\Program Files\, c:\Dekstop, f:\Program Files with my SUA and SRP and UAC activated.

Ashanta,

I do not really understand what you are trying to say with that..

btw.. the designated SRP file types are executables / programs, eg .exe, not the data files that the programs read, eg .pdf.

If you are following the Mechbgon process, the folders protected / allowed by LUA / SRP etc should be as included on there, and are fairly well described, if my memory is good..??

Not entirely sure if you are:
1) changing your set up so that all programs are installed on C:, or
2) trying to install SRP for programs on F:

If 2), Lucy has already suggested that this is probably not a good idea, and hence simply best to switch SRP off, if having problems.

If 1), and SRP was switched off, and all programs changed to C:; then switching SRP back on again in theory should be as per the set-up described, ie you can compare to Mechbgon's illustration etc..

Peter

[Ashanta]

Originally Posted by pbw3

Ashanta,

I do not really understand what you are trying to say with that..

I'm sorry I forgot one word: 'access' My question was why I can access to c: program files, c:windows\system, c:dekstop and f:program files

Originally Posted by pbw3

btw.. the designated SRP file types are executables / programs, eg .exe, not the data files that the programs read, eg .pdf.

Yes, you're right But, in my case, I can't view any pics, videos, pdf, music files with SRP activated and under a standard account


Who can tell me which files and folders are protected by SRP ?

[Ashanta]

Originally Posted by Sully

I don't use LUA or Vista much. I use XP and Admin mostly, with some testing in 7. I use SRP to restrict programs to Basic User, or deny them. SRP works perfectly for me. It does not matter what drive/path I use it works as expected. Using under LUA with a default-deny approach is much different.

Here is a good technet article on SRP.

http://technet.microsoft.com/en-us/l.../bb457006.aspx

Sul.

Thanks for the link Sully , I will read it.

What do mean by Basic User ? Under Vista, I only have standard user, guest or admin account.

[Sully]

Originally Posted by Ashanta

Thanks for the link Sully , I will read it.

What do mean by Basic User ? Under Vista, I only have standard user, guest or admin account.

You normally use one of 3 account types. Administrator, Power User and User. Power User is only slightly less powerful than Admin, so it is safest typically to have a User account, which restricts much more than Power User. SRP has option levels to apply when executing a said executable. One is deny, one is allow. Those are typical. There is also one called Basic User, where if you are Admin, you start program 'AS' a User, even though you are logged in as Admin. It is the exact same thing Drop My Rights does. So as an Admin, I use SRP to 'restrict' paths or .exe's to run 'AS' a Basic User. In doing it this way, SRP rules apply to all users 'including' admins.

When you are logged in as a User (aka LUA) you set SRP to only apply to Users, not to Admins. This way, when SRP is watching a directory/file, and you start it as normal User, it can be denied or allowed. If you right click the same item, and RunAs an Admin, the execution is now ignored by SRP because Admins are not included in SRP protection.

When you set SRP up in LUA like you have done, you basically say the default is to deny any executable except perhaps c:\windows and c:\program files. You take away for instance rights of any program to start from any other place, such as desktop. Then you also remove the .lnk from monitored extensions, so that while you cannot run a .exe from you desktop, you can run a shortcut. In any of those situations, if you were to start something as an Admin, using RunAs or SuRun or similar, then SRP is not effecting the execution because of the credentials starting the application.

Understand?

Sul.

[Sully]

I will try to find time to reinstall Vista Ultimate and play more with this matter and see why things are occuring like you state. I don't normally run in LUA, but even in XP, probably because of no UAC, it won't act as you state. I would be interested to find a solution for installing a program to a driver other than system drive and still have SRP work, but I have not tried it yet. Lucy states there is a design flaw causing this, which is probably true. But sometimes you can find ways around these things if you are looking to.

@Lucy, do you have any documention or a link describing this deficiency?

Sul.

[Ashanta]

Originally Posted by Sully

You normally use one of 3 account types. Administrator, Power User and User. Power User is only slightly less powerful than Admin, so it is safest typically to have a User account, which restricts much more than Power User. SRP has option levels to apply when executing a said
executable. One is deny, one is allow. Those are typical.

Power User and Basic User, don't work with Vista Business. We have Administrator and Standard User.

Originally Posted by Sully

There is also one called Basic User, where if you are Admin, you start program 'AS' a User, even though you are logged in as Admin.
It is the exact same thing Drop My Rights does. So as an Admin, I use SRP to 'restrict' paths or .exe's to run 'AS' a Basic User. In doing it this way, SRP rules apply to all users 'including' admins.

I couldn't start 'AS' a User when log in to my Admin account. I supposed that you're talking about clicking with right side on a file, (as we do the same with 'Run As Admin').

Originally Posted by Sully

When you are logged in as a User (aka LUA) you set SRP to only apply to Users, not to Admins.

What do you mean by 'set SRP', you mean configure gpedit.msc ?? When I'm logged to my Standard User Account, I can't launch gpedit, except with 'Run As Admin'

Originally Posted by Sully

This way, when SRP is watching a directory/file, and you start it as normal User, it can be denied or allowed. If you right click the same item, and RunAs an Admin, the execution is now ignored by SRP because Admins are not included in SRP protection.

Yes, I know that, thanks

Originally Posted by Sully

When you set SRP up in LUA like you have done, you basically say the default is to deny any executable except perhaps c:\windows and c:\program files. You take away for instance rights of any program to start from any other place, such as desktop.
Then you also remove the .lnk from monitored extensions, so that while you cannot run a .exe from you desktop, you can run a shortcut.

Yes, I go along with you, but this in theory. In my case, I couldn't run any shorcuts and any exe, any image, videos, pdf,... but on the contrary, I can access to almost all folders located in C: and in F: , even system32 and system folders.

Originally Posted by Sully

In any of those situations, if you were to start something as an Admin, using RunAs or SuRun or similar, then SRP is not effecting the execution because of the credentials starting the application.

Yes, I know that.

Originally Posted by Sully

Understand? YES

Sul.

[Ashanta]

Originally Posted by Sully

I will try to find time to reinstall Vista Ultimate and play more with this matter and see why things are occuring like you state. I don't normally run in LUA, but even in XP, probably because of no UAC, it won't act as you state. I would be interested to find a solution for installing a program to a driver other than system drive and still have SRP work, but I have not tried it yet. Lucy states there is a design flaw causing this, which is probably true. But sometimes you can find ways around these things if you are looking to.

@Lucy, do you have any documention or a link describing this deficiency?

Sul.

Thanks a lot Sul

Lucy or maybe Tlu

[Ashanta]

Sully,

Do you have news for me ? I gave you an answer to all your questions posted here: http://www.wilderssecurity.com/showp...1&postcount=16

Ashanta,

you mentioned you created an exception to allow access to your programs installed on a different partion, but did you ensure to set the "Security level" correctly as shown in the screenshot? You also state you have a whopping 94 programs installed?! That's a lot Are they all installed on the one partition or on several different partitions.

BTW, I am using Vista 32 bit with SRP and LUA, using Sandboxie and no ill effects, although I have only one partition, so this could be the stumbling block for you, where you have to designate path rule{s} for your programs installed on different partitions.

[Sully]

I have Vista Ultimate installed in vmWare with a partition. I don't normally use vista so I have a bit of catching up to do. I will poke around a bit. It is a little different for sure with a partition. There surely must be some secrets to gather out of the mess lol.

I head for vacation starting saturday, so maybe I will find some good info's before then, but maybe not, my honey-do list is building quickly before we leave lol.

Sul.

[Sully]

Okay, some more playing reveals a little.

Vista Ultimate SP1 in vmware, with an 8gb partition as d: default install etc etc

On desktop exist
setup.exe (for icon tool)
shorcut to setup.exe
shortcut to icon tool (installed into d:\program files)
shortcut to movie gallery (resides in c:\program files)

Install SBIE default.

Using PGS, set SRP for LUA where
Exclude Administrators
Include dll's
.lnk is removed from monitored extensions

Paths are default windir and program files, as well as one for PGS itself.

Try to execute and the result::
setup.exe :: SRP denied
shorcut to setup.exe :: SRP denied
shortcut to installed tool :: SRP denied
shortcut to movie gallery :: allowed
SBIE setup.exe :: SRP deny
SBIE shortcut to setup.exe :: SRP deny
SBIE shorcut to installed tool :: strange SRP deny error. not see it like that before, almost like there is missing quotes around path d:\program files, because of space in string.
SBIE shortcut to movie gallery :: error due to not enough disk space (probably SBIE limitation)

Using PGS, make these changes
ADD d:\program files as an unrestricted path

Try to execute and the result::
setup.exe :: SRP deny
shortcut to setup.exe :: SRP deny
shortcut to installed tool :: allowed
shorcut to movie gallery :: allowed
SBIE setup.exe :: SRP deny
SBIE shorcut to setup.exe :: SRP deny
SBIE shortcut to installed tool :: could not load service (dll) error
SBIE shortcut to movie gallery :: same error with not enough disc space

Using PGS, make this change
exclude dll's

Try to execute and result ::
setup.exe :: SRP deny
shortcut to setup.exe :: SRP deny
shorcut to installed tool :: allowed
shortcut to movie gallery :: allowed
SBIE setup.exe :: SRP deny
SBIE shorcut to setup.exe :: SRP deny
SBIE shortcut to installed tool :: allowed
SBIE shortcut to movie gallery :: SBIE still has limitation of disc space or something...

At this point, with only one path rule to d:\program files, the tool that is installed there works from desktop, where it either denies or allows the program to run. Further the program can extract icons from desktop, program files, windir and d: executbables and place them on the desktop.

Also, when dll's are exlcuded, SBIE can run the program that is installed to d:\program files, from a shortcut on the desktop. It can again extract icons from various directories and then successfully recover the extracted icons from the SBIE virtual desktop to the real desktop using the standard recovery prompt in SBIE.

I don't see exactly what the problem is then, based on this, unless I am missing something here.

Fill me in if I am.

Sul.

[Ashanta]

Originally Posted by wat0114

Ashanta,

you mentioned you created an exception to allow access to your programs installed on a different partion, but did you ensure to set the "Security level" correctly as shown in the screenshot? You also state you have a whopping 94 programs installed?! That's a lot Are they all installed on the one partition or on several different partitions.

BTW, I am using Vista 32 bit with SRP and LUA, using Sandboxie and no ill effects, although I have only one partition, so this could be the stumbling block for you, where you have to designate path rule{s} for your programs installed on different partitions.

My SRP is disallowed as mentioned by Mechbgon.

I've my programs installed in C:\Program Files and F:\Program Files (here, are 99% of all my programs)

[Ashanta]

Originally Posted by Sully

Install SBIE default.

Using PGS, set SRP for LUA where
Exclude Administrators
Include dll's
.lnk is removed from monitored extensions

Thanks a lot for your time Sully

I've the same settings on my SRP

Originally Posted by Sully

Try to execute and the result::
setup.exe :: SRP denied
shorcut to setup.exe :: SRP denied
shortcut to installed tool :: SRP denied
shortcut to movie gallery :: allowed
SBIE setup.exe :: SRP deny
SBIE shortcut to setup.exe :: SRP deny
SBIE shorcut to installed tool :: strange SRP deny error. not see it like that before, almost like there is missing quotes around path d:\program files, because of space in string.
SBIE shortcut to movie gallery :: error due to not enough disk space (probably SBIE limitation)

I'm agree with your results. In my case, when clicking on SBIE shorcut, I have a dll error.

Originally Posted by Sully

Using PGS, make these changes
ADD d:\program files as an unrestricted path

Try to execute and the result::
setup.exe :: SRP deny
shortcut to setup.exe :: SRP deny
shortcut to installed tool :: allowed
shorcut to movie gallery :: allowed
SBIE setup.exe :: SRP deny
SBIE shorcut to setup.exe :: SRP deny
SBIE shortcut to installed tool :: could not load service (dll) error
SBIE shortcut to movie gallery :: same error with not enough disc space

Using PGS, make this change
exclude dll's

Try to execute and result ::
setup.exe :: SRP deny
shortcut to setup.exe :: SRP deny
shorcut to installed tool :: allowed
shortcut to movie gallery :: allowed
SBIE setup.exe :: SRP deny
SBIE shorcut to setup.exe :: SRP deny
SBIE shortcut to installed tool :: allowed
SBIE shortcut to movie gallery :: SBIE still has limitation of disc space or something...

I don't have PGS installed on my computer, so that I can't verify your results.

If you add d:\program files as an unrestricted path and exclude dll's, the program files folder and all the dll are not anymore protected by SRP. So, I need a program to protect these files like MD or GW, I suppose. I understand that my SRP was to strictly, even if it was the default deny.

Originally Posted by Sully

Also, when dll's are exlcuded, SBIE can run the program that is installed to d:\program files, from a shortcut on the desktop. It can again extract icons from various directories and then successfully recover the extracted icons from the SBIE virtual desktop to the real desktop using the standard recovery prompt in SBIE.

For that, I need to exclude dll's and add f:\program files\ in the additional rules

I know this, but If I do what you suggested, these files are not anymore protected, that was the point. In this way, I need an extra Hips software like MD, GW or DW.

Originally Posted by Ashanta

My SRP is disallowed as mentioned by Mechbgon.

I've my programs installed in C:\Program Files and F:\Program Files (here, are 99% of all my programs)

Understood, but my screenshot shows an additional "Path Rule" that could allow you access to certain paths, such as the programs installed on your F partition. Maybe I'm missing the boat, however, so my apologies if I'm posting inapplicable info.

[Sully]

Ashanta, perhaps you don't grasp fully what SRP default-deny is supposed to do. You can have it two ways. First, you can dictate very simply, no program run in d:\program files. Default-deny. If you need something to run, you make a specific path rule for it to run only. This way all program files are still default-denied, but your few exceptions are allowed.

Second, you allow d:\program files, and allow anything in there to run, the same as windows directory. But you still have user space locked down from running anything but .lnk files, and then the .lnk files must point to an executable within an unrestricted path in SRP. In this manner, your programs are installed by admin account to program files, your shorcuts are allowed execution, and if they point to program files they run as normal. But, your user space is denied any executable from running, even if they are attempted with a shortcut.

You don't really need another HIPS, you just need to decide if you trust what is already installed or if you only trust a specific few. Don't forget, that as you execute some program in d:\program files, it is being run as a User only, so what you achieve is locking down running of applications you don't want or are not in places you trust.

HTH.

Sul.