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/showthread.php?t=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]

-{ Quote: "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.

-{ Quote: "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.

-{ Quote: "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.

-{ Quote: "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]

-{ Quote: "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).

-{ Quote: "Disable SRP and the problem goes away? " }- YES, the problem goes away.

-{ Quote: "Enable and it exists again? " }-Yes, indeed.

-{ Quote: "If you remove SRP, does PE or AU run normally?" }- Yes, it works !

-{ Quote: "Then enable SRP and they fail." }- Yes again !

-{ Quote: " 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 ?


-{ Quote: "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.

-{ Quote: "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]

-{ Quote: "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/library/bb457006.aspx

Sul.

[pbw3]

-{ Quote: "??? 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]

-{ Quote: "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



-{ Quote: "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 :thumb: 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]

-{ Quote: "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/library/bb457006.aspx

Sul." }-

Thanks for the link Sully , I will read it. :thumb:

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

[Sully]

-{ Quote: "Thanks for the link Sully , I will read it. :thumb:

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]

-{ Quote: "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.


-{ Quote: "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').


-{ Quote: "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'

-{ Quote: "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 :thumb:

-{ Quote: "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.

-{ Quote: "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.

-{ Quote: "Understand? YES :)

Sul. " }-

[Ashanta]

-{ Quote: "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/showpost.php?p=1521311&postcount=16

[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 :o 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]

-{ Quote: "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 :o 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]

-{ Quote: "
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 ;)


-{ Quote: "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.

-{ Quote: "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.


-{ Quote: "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.

[wat0114]

-{ Quote: "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.

[wat0114]

-{ Quote: "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." }-

Sully is right, and here is a custom path rule that allows the programs installed on the D partition on our XP machine (it has a C & D partition) to be used under a limited account, otherwise without this exception rule, there is no way a limited user can launch these programs.

[Ashanta]

-{ Quote: "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." }-


Thanks for your reply Sully,

I had already understood what you explained in your post. As you know, I already added rules from my first post. It wasn't a matter of how to do it with SRP.

What I wanted was:
the default deny SRP with disallowed, all files, all users except admin and without adding rules, and be able to run with my SUA and UAC enabled, 'Run As Admin' all the programs. At the same time, SRP locked all the programs and I could 'Run As Admin' whatever programs I'd like.

What I don't want is adding extra rules, because these folders and files were not locked and protected anymore by SRP.

That's was the point !;)

[Sully]

-{ Quote: "
What I wanted was:
the default deny SRP with disallowed, all files, all users except admin and without adding rules, and be able to run with my SUA and UAC enabled, 'Run As Admin' all the programs. At the same time, SRP locked all the programs and I could 'Run As Admin' whatever programs I'd like.

What I don't want is adding extra rules, because these folders and files were not locked and protected anymore by SRP.

That's was the point !;)" }-
Right. But first break down the equation.

1) you are user, call it SUA/LUA or just user, either way you are user.
2) you plan to use UAC to escelate to Admin when needed
3) you wish to lock all programs for User, but not for Admin, which has to 'RunAs' because of LUA/SUA
4) you do not wish to add extra rules -- hmm.

So to solve for this equation then, we must

1) make us a User -- easy.
2) keep UAC enabled -- easy.
3) engage SRP, where deny is the default policy, and it only applies to users NOT admins -- easy.
4) no extra rules -- this is where it breaks down ! You must add extra rules unless you only want to run what is native to SRP, which is anything in c:\windir and c:\program files. All other paths are intrinsically locked because by default SRP only allow execution of those two paths.

So, we can examine more closely what you can expect, or should be able to expect under normal conditions.

As a User you can execute within %windir% and %programfiles%, wherever the path says they are. You cannot execute from any other path, including %profiledir%, this includes the desktop. By default .lnk is denied for a User, so your shortcuts will not work. This is obviously why you remove the .lnk so you can start items in %windir% and %programfiles% easily with links instead of directly from thier respective parent directories.

In your case, you wish to execute something as an Admin, using UAC/RunAs/SuRun or whatever. This should pose no problem normally because Admins are not included in the SRP policies.

But you say you don't want to add extra rules. I will read further into this than you mean because someone else will read this and might not understand. In your case you have installed programs to K:\program files\programs.. SRP by default does not know of this, and when you execute as a User, SRP dutifully says no, it is not allowed.

Should you run as Admin, SRP ignores you because it is supposed to. So the only way you will ever get SRP to allow the User to execute anything in K:\Program Files\... is to make a rule for it. The rule can be wide open, thus k:\program files\* would work, or perhaps you know only a few programs you will like to allow and make more specific path rules for just those. The same goes for any other directory other than something within %windir% or %programfiles%, it will need a rule applied to allow it.

Now let us look at Sandboxie in this context. As a user, you are allowed to run anything within %programfiles%, so you can start SBIE itself without issue. So if you choose to start iexplore.exe in SBIE, it is no issue. But in your case, you have maybe firefox installed to k:\program files\mozilla\firefox, so when you execute firefox.exe into SBIE, SRP intercepts and says there is no rule for K:\program files\mozilla\firefox\firefox.exe, and it denies it. Even though SBIE is allowed, SRP is blind. SRP only cares about 2 things, if there is a path allowing, and if it is Admin or User requesting. Thus, adding the extra rule into SRP to allow K:\program files solves this issue.

Whether or not dll inclusion can be turned on or not seems to be up in the air. Whether you would have to add c:\sandbox to SRP path rule is also something up in the air. I did not try, but could imagine that possibly you tried to execute from within sandbox you will have 2 results.

First, execution is read by SRP, and it sees the legitimate path as c:\sandbox\drive\program files\path\program.exe, and it refuses because in there is no path rule for c:\sandbox* and default-deny means to deny.

Second, execution is read by SRP, but it sees the virtual path c:\program files\path\program.exe and processes accordingly. Which of course means the program could execute because SRP thinks the path is a real path not a virtual one.

Now that all that is done, if I read you correctly, you are wishing to engage SRP default-deny, which locks all but %windir% and %programfiles%. You then wish to run as SUA/LUA, and with no extra path rules, nothing is allowed but those 2 defaults. Then, you wish to login as SUA/LUA, and only run, as Admin, via UAC/RunAs the specific programs you wish. Leaving you with normal use, no program at all ever running, as a User, unless you very specifically start it as an Admin. I think that is what you are wanting.

So you could leave %windir% in place, and then open very specific %programfiles% directories to fine tune just what cannot be ran. This way then, you lock down much more to never running unless you specifically say so, and then only as Admin.

I like your crooked way of thinking, right along the lines of what I would do. But I must ask, what would you find to be advantageous of running programs as Admin only? You realize of course that as an example, you do this thing you are thinking. Login as User, nothing runs, but you start Firefox to browse, and the only possible way is to start as Admin, because that is how your system is designed to be. So FF starts, but as Admin. Now you have given root privelages to a program that is connected to the wild world of wierdos (aka www) and have no recourse to stop what it might do except through means other than the OS is offering.

I see your madness though with the inclusion of SBIE. You wish to lock down anything, but run everything in SBIE maybe? Thinking this way, you start the computer, nothing can run because of SRP, and with UAC/RunAs you need to give permission to start as Admin. So now you can start Firefox as Admin, but also have SBIE forcing Firefox into a sandbox. This way, only what you want starts, requires specific action to start, and when it does is automatically forced into SBIE.

Am I even close to what you are thinking? lol, it seems so. I love looking at and trying things from obtuse angles, just like this. Or maybe I don't know jack beans.

Yeah, forgive this long-winded post and not assuming you don't know, just putting it out there in case someone else might find it useful.

Sul.