term "default deny"

More to the point, a binary file is a binary file, and executed the same way regardless of the extension. Similarly, SRP blocks binaries by the method used to execute them.

See:

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

There's what Windows considers executable files regardless of extension, then there's that list, which contains duplicates if you will. Binary files because of what they are, script files like bat and vbs because the interpreter was written by MS, and made aware of SRP, and consult them before executing code.

If the interpreter is, say Python, then that depends on how Python developers coded it. If they didn't do anything about it, Windows blocks .py files only if they are on the list and if executed by explorer.exe (or IE i think).

 

As I've said (I think), SRP, when the default rule is to deny and the logged in account falls under the denial, will attempt to block all executables. The definition of executable is probably a confusing factor here because of the file extension list.

If you did not have those 2 default rules in place (as we all know) then nothing would run. I don't even know if you could boot up. If the policy takes effect after logon, then maybe things would mostly boot up, but it it takes place during boot and before login, who knows what might not be allowed to start and thus really mess things up.

I really think (after thinking about it more lol) the file extension list is all of the afore-mentioned. It is a black list of sorts, it is a white list of sorts. It can be used or not used, all depending on the rules in place. The problem here is the fact that double clicking on an item allows shell execution. Get rid of that feature (perish the thought, right ) and you no longer care about extensions, only which program is allowed or denied.

If this were put on Linux, would it be the same thing? Needing to have sysdirs excluded from default deny for the OS to work correctly? Needing a way to keep track of all files of a certain type from being shell executed rather than restricting the interpreter ?

It really isn't that complex, nor is it really important. Some of us just like to hear how others view it and are interested. I know for me, even if this proves nothing in the end and does not create world peace, I find it a great way to challenge my own viewpoints, and possibly modify them if needed.

Sul.

 

That was never my doubt, actually. I know that both SRP and AppLocker don't look at file extensions.

My point was/is that SRP will not ignore the file types mentioned in the Designated File Types list.

They do serve a purpose, otherwise they would just be useless, wouldn't you say?

So, I ask: What does that list of file types exist for? What is your understanding of this? I already know that SRP doesn't look/or just look at the file extensions; but what do you make out of what is mentioned about the Designated File Types?

Microsoft explains this

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

How do you interpret what's bold?

 

I'm putting all my chips on the fact that it is a convenience. Convenient to disallow a wildcard - an extension. Or allow it, depending how you look at it.

Example:

(bear in mind we are no longer discussing what default deny is -- we are discussing how and why SRP uses a file extension list and what that implies -- in a typical default deny scenario -- education only)

Since cmd.exe resides in a default allowed directory, the inclusion of .bat into the extension list will set a system wide ban on any .bat from being "construed as" an executable (unless the .bat file also lives in an allowed directory) * (.bat files are not being construed as a binary executable, but as a file type that is registered and thus only requires shellexecute to run - in other words you just have to double click it to make it do what it needs to do - perhaps considered dangerous because it is so easy to do). Without the extension list, it is an all or nothing affair. Either all .bat files are allowed to run because cmd.exe is allowed, or denying cmd.exe denies all .bat files.

One might also look at it like this. According to the functionality of SRP, if there were no file extension list, and cmd.exe needed to remain as an excluded object, one would have to make a deny *.bat rule to block all .bat files while still allowing cmd.exe to be allowed.

Depending on the differing rules, certain precedence/hierarchy takes. Place the Denies are given more weight than the allow. The specific path rules are given more weight than the generic wild card rules.

Why not just include a simple deny *.bat rule. And a rule for denying *.vbs. This would also have taken care of the issues. Is it because of certain idiosyncrasies in the precedence/hierarchy perhaps causing problems? Or is it the sheer amount of rules needing to be made for every registered file type that might wish to use things like cmd.exe, cscript.exe or rundll32.exe?

** one might also ask a question that begs an answer -- I just tested this. If you remove .bat from the file extension list, and have the default 2 rules in place, you can run any .bat file. But if you then create a rule to deny *.bat or a specific .bat file, SRP does deny it. Why? A .bat file is only a script. Cmd.exe is allowed. Why would SRP deny a .bat file when it is a text file? It doesn't deny a .txt file. The inclusion of .bat to the file extension list seems to have nothing to with anything other than a convenient way to target all files of a certain file type extension **

Who can say. After a lot of thought and reviewing my data and the viewpoints offered in threads like this, I really think it came out of convenience. Convenient way to avoid possible collisions of precedence/hierarchy and convenient way to not have to create many rules by using a list of file types to do the grouping.

Sul.

 

Wow!!!!!

This is a thread I will never forget!

Thanks to this discussion on just what the file extensions really mean, I have stumbled on a way to make the Basic User setting work in Windows 7 !!!

Maybe someone else can try this out....

Create SRP policies - 2 default rules. The default action is Unrestricted - make sure it is so. The default setting is to apply to all users INCLUDING admins - make sure it is so.

Create a batch file on desktop (or wherever) with this in it:

Code:

md "c:\program files\a1mydir"
pause
rd "c:\program files\a1mydir"
pause

Add a path rule for that .bat file and set to Basic User. Run .bat file. You should get denied. This is what I always have gotten with win7.

Now remove .bat from the file extension list. Run .bat file. You should see that the console now says "access denied". This is the Basic User/restricted setting.

I don't recall where my UAC is at, either completely disabled or at lowest setting (too much coding/testing to keep track of it lol). I will find out tommorrow though.

This is so very interesting. Here we are discussing what the purpose of this list is, and behold, it actually effects something that is positive.

Thanks to all who spurred this on. I think I am most happy now

Sul.

EDIT: SWEEET! If you remove a file extension for .reg, then apply Basic User to a directory, a .reg file can be ran that modifies HKCU, but not HKLM. If you don't remove the .reg from the extension list, then the Basic User setting denies the .reg file from running at all, even if you right click on it and "edit" it. If you start notepad.exe, then drag/drop the .reg file it will open and save etc.

Very interesting stuff here...

EDIT: AGAIN: This is very cool. When you enable basic user for a directory, if you execute something that resides on the file extension list, it is denied. If you remove it from the list, it might run, but with restricted token. This 'might' mean that SRP in win7 is able to, from admin, using Basic User, both deny in certain instances "good for download directory" but also allow specific file types to run at restricted level if the extension isn't listed. Take some more testing, but hopefully it pans out this way....

Couple SRP in this fashion with Integrity Levels and Compatability Layers, you might have a dynamic setup, far beyond a simple deny execute. (can you tell I am licking my chops at the mere thought )

 

Sully, and I couldn't agree more! This is where I wanted to get: the Designated File Types list, which includes extensions exists as a convenience; either to allow or disallow that same/those same extensions.

Well, the rest you just explained it there very well. Maybe my limitation was my English not being properly expressed sometimes.

But, it seems we are on the same chapter now, I'd say.

 

I'm glad you found something really positive for you out of this! Really nice stuff indeed.

I guess you've found something for myself to play with a lot more. lol

 

Sully's wheels are spinning again, maybe thinking about revamping his Safe Admin project in favor of a hybrid Safe/SRP/Admin or similar His partner Kees will soon follow suit

 

lol, that is funny, yet disturbingly accurate

The SafeAdmin project is coming along nicely, although it is much more in-depth than I had anticipated, which is a good thing.

Some of this SRP stuff I am looking at now could open new doors for different methods. For instance the SRP polices seem to apply before ACL deny execute does. I haven't played with enough of it yet (a mere 5 hours ) to wrap myself fully around it, but in win7 things are just different enough I keep finding myself backtracking alot, thinking "what? why did that happen?".

I can't say it will go anywhere, but much of today was devoted to SRP. Found some interesting stuff out and will be seeking to see how the different layers interact -- SRP, ACL, IL, Zones and AppCompatability.

Who knows where it may go, but no matter what it turns out, the SAFE project is now set in stone. Too much time devoted to radically change it now. Besides, it has turned out thus far so much better than I ever thought it would have.

Sul.