term "default deny"

Discussion in 'other security issues & news' started by gambla, Nov 9, 2010.

Thread Status:
Not open for further replies.
  1. Lucy

    Lucy Registered Member

    Joined:
    Apr 25, 2006
    Posts:
    404
    Location:
    France
    m00nbl00d,

    I am afraid , from my understanding, that you didn't manage to understand the difference between how and what.

    "How" refers to the kind of poilicy. For a given file type, how will I handle my strategy? Will I default deny? Will I default allow and only restrict specific files from this file type?

    "What" refers to the item I am about to apply the policy to. In other words the file type.

    By design and by philosophy, SRP was primarily designed as a default deny (therefore whitelisting) in regards to security purposes. M$ and the specialists on the web, all define SRP in this way.
    For administration purposes, it can be implemented as a black listing application. But SRP is not used as a security application tool, but rather as an administrative tool.
     
  2. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    I understand the how and the what.

    The default policy of SRP is Unrestricted, which means Blacklisting. You need to set it to Disallowed, making it default behavior, meaning Whitelisting. So, when I mentioned SRP default behavior is default-allow (Blacklisting), I was right, because one needs to change it to Whitelisting (default-deny).

    I do know what I am talking about. I have no problems understanding what SRP is and what default behavior is. What I am trying to understand, taking Sully's perspective, is how can it be that what's in the types list isn't a blacklist of some sort. In my conception, it is, due to the way it appears to work.

    Again, I never used SRP deeply, and never really looked into what it implies, besides the default, or not, behavior.
     
  3. wat0114

    wat0114 Guest

    It just comes down to how one perceives things. You perceive SRP's default-deny functionality a bit differently than others in this thread, but it seems clear to me that you understand how SRP works to secure a desktop, and that is, after all, what's really important :) No one is here to prove "I'm right and you're wrong so haha", only that it's a discussion to see how a number of us perceive things. For me it's been enlightening, because others have stated things about default-deny that I never knew about or thought of before, giving me a heightened understanding of what it's about.

    If I'm not mistaken, doesn't that default policy in effect do nothing, essentially keeping things status quo?
    Code:
    Software access rights are determined by the access rights of the user.
    I've always thought of it as just a starting point for those deploying an SRP policy, though maybe I'm wrong on this.
     
  4. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    From the perspective as an Admin (full Admin., as in UAC disabled) with *.bat in the list, blocked execution. Removing it, allowed to execute *.bat.

    I just tested it.
     
  5. safeguy

    safeguy Registered Member

    Joined:
    Jun 14, 2010
    Posts:
    1,797
    I agree with Lucy but I've to write...can't help it.:oops:

    I'm sorry to say but whatever you're saying is contrary to what your objective of discussion is. If you allow it to execute, it'd definitely beat the purpose of SRP. Why? Because you removed it. You allowed it. Same goes for any default-deny strategy you can think of. Even AppLocker. Even NoScript. Just because one can make an exclusion to a default-deny strategy doesn't make the tool a 'default-allow' tool/concept.

    As far as I can tell, you've been here for a long time and I'm pretty sure you know very well what you're talking about. Isn't the concept of white-listing is to in fact "blacklist almost or as much as everything possible unless we define some exceptions to the default rule". Which is what Sully's trying to explain although he uses more difficult terms to bring out the point. I'm not good with technicalities and hence I leave it to others to do the job.

    You claim that "It's not in discussion if one should or can or will remove anything from Executable File Type List." but that's what you are doing. If you don't remove it, period...it blocks it for you. By adding complications and "what if scenarios", you're just complicating the concept and confusing the terms 'default-deny' and 'default-allow'. And that's where I feel I have to step in and post my thoughts over this...not to annoy/argue with anyone, less so if the guy knows what he's talking about.

    Please feel free to discuss SRP in-depth, "how it really works", etc but please don't claim that it's a default-allow strategy (unless you didn't use the method mentioned by mechbgon) if you yourself had removed the exclusion list. Not only are you confusing yourself but any newbie who comes and read this thread...

    In simple terms:

    White and black goes in hand, without black, how would someone know it's white? People always think of opposites as nothing more than opposites but they fail to realize that opposites work hand in hand. If you really want something that's "purely and 100% bullet-proof default-deny", you wouldn't even be able to open up that .jpg file or run that .flv video you downloaded from the web in Applocker/SRP/any default-deny tools that's present today. Heck, there's so many code beyond simple file-type extension that is practically unachievable in a default-deny concept that you're talking about. Unless you are willing to turn off your PC that is:p

    Since you said you hadn't used SRP for long, I'd suggest (as a friendly gesture) to read about SRP here:

    How Software Restriction Policies Work

    In accordance to what you're query is about, I've quoted upon these words for simple reference sake:

    In simple terms: SRP does not work by only by extensions. SRP will intercept whenever an executable code is the ultimate payload when it's loaded by Windows Explorer or Internet Explorer. And that is where lies most of the threats in the current landscape if I'm not wrong. Some guys over here have figured out that it's possible to launch certain exploits using the command prompt, wscript.exe, etc, etc and they'd recommend that you add in those "loopholes" to your Designated file Types List. That's where the Designated File Types Properties dialog box comes in useful...apart from being an additional tool for you to add-in certain file types that is loaded by a program that "does not enforce software restriction policies itself", it also enables you to strengthen upon how your SRP works. (in rare cases or POCs) In normal day-to-day usage, SRP in it's default form as mentioned by mechbgon is as good as it can get.

    One may consider this as a form of "blacklisting" but like I've said earlier on, the concept of white-listing is to in fact "blacklist almost or as much as everything possible unless we define some exceptions to the default rule". In this case, the default rule may not be the strongest and that's where we tweaked it to our flexibility and needs. Instead of seeing this as a weak point, see it as a point of strength. You are the one in charge of adding rules to how your white-list works. I have always remembered that nothing is ever perfect and flaws are always discovered...and that same principle applies to white-listing or default-deny concept. White-listing isn't the perfect cure to everything as some people try to sell it off as...

    As for differences of Applocker (that you mentioned in your 1st post in this thread) against SRP, please see this:

    How does AppLocker differ from Software Restriction Policies (SRP)?

    If you notice, apart from differences, they do have similarities, especially the fact that they are both based on rules. AppLocker too blocks according to rules. And those rules are in the concept of "blacklisting" if we were to follow what you say. Does that make AppLocker a default-allow strategy? Nope, as far as I'm concerned, it doesn't.

    In addition,you might be interested to follow through this long thread which finds and uncovers certain surprises on how SRP works (which is where I got most of my info mainly from):

    Software Restriction Policy vs Antiexecutable

    Adios:D :D

    P.S. I can be long-winded...forgive my rant if you can. I mean no harm cause I'm safeguy. :)
     
  6. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    I'm not arguing that. The simple fact is that SRP default policiy is not a default-deny, it's rather a default-allow. I know this; you know that. What about others? Most likely they would think it's OK like that. Which is why I mentioned a link to the NSA PDF file explaining how to set a default-deny (Whitelisting); which for me seems to be a great article. :)
     
  7. safeguy

    safeguy Registered Member

    Joined:
    Jun 14, 2010
    Posts:
    1,797
    Dude...the one who sets what policy as default is the end-user or the "Admin". Most people who do not know what SRP is lands up being recommended to follow the default-deny method. Please for the sake of discussion not confuse the user with the 2-3 different options available in SRP. There's also the "Basic User" mode that Sully claims to use when he's on XP last time on another post...
     
  8. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    What does that has got to do with anything o_O No one's talking about removing nothing. It's a mere mind exercise.

    I totally agree with you! Whitelisting something, means we're blacklisting everything else. Blacklisting something means we're allowing everything else.

    So o_O

    These two terms do exist. I didn't make them up. I'm just exercising my mind based on this very same fact.

    No, it's not. I'm doing nothing. I'm merely trying to understand why the Designated File Types list blocks if XYZ file type is in it, and why allows it, if not. Well, actually not trying to understand this, but whether or not this is a/some sort of a blacklist/whitelist. It is actually both, because if not present, then it is allowed. But, if present, then blacklisted. So, it's not merely for improved performance. I just can't see it like that.

    So, now I'm forbidden to try to understand better, if I'm wrong, from other more knowledgeable people? OK. I won't write anymore, after this my last post, if it bothers you that much.

    I also don't see how this confuses what is a default-deny or default-allow. It's more than clear, and more than explained, and not what I'm really debating, though related to SRP itself.

    The DEFAULT policy is UNRESTRICTED - default-allow. I'm not the one making this up. Just set up SRP and see what comes up by default.

    I'll stop quoting here, as I'm tired quoting, but I get the idea you seem not to understand, which is your right.
     
  9. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    Actually, when SRP is created for the first time, the default policy is Unrestricted. I actually do have to change it to Disallowed, manually. I do agree with that. But, how does this make it not be a default policy (Unrestricted)?
     
  10. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    -Edit-

    By the way, what does the mechbgon method has got to do with anything o_O
     
  11. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    I think it all stems from the fact that much can be called an executable, even though it is not itself really that. If we think of a .vbs file, it is considered an executable file type because it is registered to use an engine which is an executable, like cscript.exe.

    .ocx, .dll, .reg, .vb - none of these will do anything without something like rundll32 or cscript to actually work. If you create a file called myprogram.wild, and double click it, it will do nothing, because the OS doesn't know what to do with it. If you open it with notepad, maybe it is only a text file.

    If it is a true executable, then it allocates resources to itself and become a process, idependent of another executable (in simple terms).

    When I think of default deny, I think of any stand alone real executable being denied. Firefox.exe, mplayer.exe, etc etc. If I wanted to block .bat files, I might just never allow cmd.exe from running. That wouldn't be really that handy, so it would be easier to only put a block on .bat files instead. This way I can still use cmd.exe for any other purpose.

    When I think of SRP being a Default Deny tool, I think of it not allowing any executable to run except those I have laid out specific rules for. It is sometimes confusing because the OS depends on many programs to run correctly. If you were to build a program that opened .test files, placed it in c:\mytest\mytest.exe and then tried to open testfile.test, it would not work. If you registered the .test file type so that it by default opened with mytest.exe, then opening testfile.test would try to work, but SRP would deny it because mytest.exe does not live in an approved directory.

    Now imagine that mytest.exe lives in c:\windows. We must allow access to c:\windows for the OS to work properly. Now when we execute testfile.test, it will work because mytest.exe lives in an approved place. We would need to add the .test file type to the File Type list. Then it would be denied if the .test file did not also live in c:\windows.

    It is both simple to understand and confusing. You have a list of file types that is only pertinent if the working binary (executable) is in an approved directory (white listed), yet if the working binary resides outside of an approved directory, you don't need the file type list at all.

    SRP never gets boring to me for some reason.

    Sul.
     
  12. safeguy

    safeguy Registered Member

    Joined:
    Jun 14, 2010
    Posts:
    1,797
    Talking and doing are 2 different things. You were indeed talking about if, even in the namesake of mere mind exercise. I'm not here to argue with anyone but merely trying to figure out your train of thoughts and letting mine flow too. Unfortunately, we are not the only ones reading/posting on this forum and you seem to be determined to declare SRP as a default-allow concept when almost anyone else around here that I see using it think otherwise. And that adds to the confusion. Am I not entitled to speak around here? Is it because I'm someone new to the forum?

    So o_O It means everything to whatever you, me and anyone is talking about here. If you were to simply take off that slight proud tone of yours and start reading with an open mind (mere mind exercise) instead of just trying to find faults with each and every single word I say, you could achieve a lot more.

    Same goes for me. Thank you:D

    It's not that you can't see it. You refuse to see it. Well, at least now you see it. Or do you?

    It doesn't bother me...not in the negative sense you're portraying it as. It intrigues my mind as to why you're so determined to prove that SRP isn't default-deny. Not even when using the method used by most here. (initially) Please take a step back and read what you've written.

    It confuses because you;re talking on different terms from everyone else initially...all I'm trying to do is find that balance. But it's fine now...I assume you're not plain interested since you're the more knowledgeable one. I give up.

    What a nice argument. Let me say this if you don't mind: The 'default' setup you mention is the way it is because that's how the state of the account is when it is initially created. Come on...just because you load up Group Policy Editor and SRP says the "unrestricted" is the default makes it the default policy? YOU are the one who decides how you would set the 'default policy' you wish to use for SRP - be it default-allow or default-deny. Now let me say this: Right-click on each of those options and tell me what do you see? Doesn't it say "set as default"o_O?

    And nope, I'm not making this up either.

    I have to follow suit. Thanks for the exercise though...it's quite some time since I last had it. If needed, I'll apologize if I sound rude in any way/form or I had hurt your feelings unknowingly because by far and by large that isn't my intention. Now I know that I should just shut up when I see one of your other posts...coz here I am thinking that 'hey this man is cool' but it turned out to be not as how I expected it to be.

    P.S. I'm sorry to all Mods and everyone reading this thread who feels I've hijacked and destroyed it. I'll forbid myself from saying any further words here.
     
  13. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    OK. Let's see. There is the Default, which is Unrestricted, and that's what I mentioned. This Unrestricted status means the blacklisting approach if one does not change it to Disallowed (I'm leaving Basic User aside), which means Whitelisting.

    I'm not here debating whether one should follow one approach or the other. It's up to the user, as you well mentioned, to decide to follow either a default-allow (which is what is created by default) or default-deny, which one may change to that. I believe we both agree on this one here. No confusion with this. It is what it is, and there's nothing one can argue about it.

    Unlike AppLocker, which when you set it up the first time, already is set with a white-listing approach in mind (default-deny). One may set it to black-listing, though.
    Again, nothing confusing here. It's what it is.

    So, the default policy is a default-allow, because that's what's set when one first creates SRP. As you well say, it's up the user to change it or keep it as a default-allow.

    http://www.windowsitpro.com/print/security/AppLocker-in-Windows-Server-2008-R2-and-Windows-7.aspx

    -Edit-

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

    SRP Default rule action: Allow and deny

    From here it's easily understandable that, by default it's allowed, but as you well said the user may change it to deny.

    AppLocker Default rule action: Deny
     
    Last edited: Nov 10, 2010
  14. wat0114

    wat0114 Guest

    The default ruleset with Applocker is meant to be and recommended by MS to be used only as a starting point when creating a policy:

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

    I'm thinking that's also the intent with the default policy in SRP. It makes no sense to me to deploy an SRP policy using the "Unrestricted" security level.
     
  15. J_L

    J_L Registered Member

    Joined:
    Nov 6, 2009
    Posts:
    8,738
    SRP is default-allow for obvious compatibility reasons.
    The average user cannot comprehend it and will complain if their software doesn't run properly.
     
  16. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    What you say is all 100% correct. I never debated that. First, I only stated that SRP default policy is default-allow. I never really understood all the fuss with it. It's what it is. If the user wishes to change it to default-deny (recommended), so be it. Otherwise, let it be as what is defined as by default.

    Same for AppLocker. I never debated which policy should be applied by XYZ person. I merely pointed out which default policy is applied when first creating SRP. Next time, I'll just won't mention anything, related or not to SRP. It's best for one just not to mention a thing.

    My debate with Sully only had to do with Designated File Types list. Not which default policy is applied. That's why I never really understood all the fuss with default or non-default policies, but that's OK.

    Reality is, Sully expressed very well his point of view, and I tried to express mine the best way I could, which from how I see it (looking at all technical details) makes all the sense, due to the way things happen if one adds or removes a file type from that list. This is what made me have the debate I had with Sully. A healthy one, I must add. All the rest, was a fuss created without any reason, taking as a point start the default policy, which after 2 posts or so I stopped talking about, because it's or was clear enough that SRP default policy is default-allow, whether or not one keeps it. The same way AppLocker default policy is default-deny, whether one keeps it or not.

    So much fuss for nothing.

    Anyway, this was the last time I actually tried to give some help, and pointing out directions to others, so they can implement a proper security policy.
    It seems most were actually more concerned trying to prove me wrong, by stating that default-policy is default-deny, rather than explaining that by default it's default-allow and that users change it to default-deny and what best approach to actually improve that very same default-deny. I tried to do that by pointing out the NSA article, which IMO is a great one. But, this taught me a lesson: Be shut up.
     
  17. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    Looking back thru this thread, it's clear that default-deny means different things to different people. A lot of the posts explain default-deny in terms of how SRP and UAC addresses it. Default-deny has been around a lot longer than either of these. I've been relying on default-deny for a lot longer than I've had versions of Windows that could implement the policy with built in tools. Default-deny isn't a utility or system component. It's a security policy. In its purest sense, default-deny doesn't treat the program files, windows, or system folders any differently than any other. That is part of Windows and how its built in tools work. If default-deny is enforced by a classic HIPS for instance, those folders and the executables in them won't be treated any differently than any others in a different location. With SSM for instance, what matters is the hash of the executable and its system path. Change either and SSM will block it. The better classic HIPS programs could be configured to allow all executables in the windows and program files folders if one chose to do so. I'd never make such a rule as I don't trust any version of Windows to completely protect the contents of those folders.

    It doesn't matter if you're using SRP, classic HIPS, or something else. These don't make the security policy default-deny, default-permit, or a hybrid of the 2. Your policy does that. These tools enforce it. Because of differences in the way they're designed, they all function differently. Most can enforce either policy, or no policy at all if the user hasn't thought through exactly what they want to accomplish. If you're securing a system with policy, start with determining exactly what you need and what you specifically want to accomplish, then choose the tool that's best suited for that scenario.
     
  18. Pedro

    Pedro Registered Member

    Joined:
    Nov 2, 2006
    Posts:
    3,502
    You can look at it that way, but you're really overly analyzing it. Glass half full or empty and all that.

    SRP by default is off.
    When we refer to the use of SRP, we imply using the policy default deny, which gpedit suggests as soon as you start using it.
    One experiment: leave SRP on, remove .bat from the list as you say. But don't try to execute a real batch file with .bat extension, try launching process explorer from the desktop, as procexp.bat . I bet it won't fly.
    Because .exe is still on the list. Process Explorer is a binary executable, ultimately run (or not) by CreateProcess(), and a real .bat is run by another binary executable in Windows folder - cmd.exe i think - which is allowed to run when CreateProcess() consults the SRP.
     
    Last edited: Nov 11, 2010
  19. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    Yes, SRP is off by default, that's why I mentioned when first created/executed. (Makes sense, no?)

    What I refer, or whoever refers as what method should be applied is no relevance to what's the default SRP behavior, which is default-allow. One can always change to one's desires, as long as it is allowed by the limitations, or lack of them, of a tool.

    Group Policy Editor never suggested me any method, be it default-allow, default-deny or basic user. The method first applied is default-allow, and then one either keeps it that way (not recommended), change to Disallowed (default-deny) or Basic User.

    That's because both %PROGRAMFILES% and %WINDIR% are allowed in the SRP, by default, and cmd.exe is at %WINDIR%\System32, which is why *.bat files are allowed.

    Blacklist C:\Windows\System32\cmd.exe and see if you still can execute *.bat files, even if you keep *.bat file in the Designated File Types list, as it is by default. You won't be able to run the *.bat file, because the executable that actually executes them is being blocked execution.

    Either way, blacklisting cmd.exe or removing *.bat from the file types list, *.bat files will be blocked. So, ultimately, SRP is checking whether or not such permissions are blocked, either against what's allowed/blocked by the SRP paths (ProgramFiles and Windows dir), to cmd.exe or a *.bat file; depending on the scenario.

    I simply can't see that the Designated File Types list is a way for SRP to ignore such file types.

    Most likely scenario, for the sake of performance, SRP checks for both allowed paths (checking every blacklisted, as in not specified as being allowed would decrease performance) and for the specified file types in the Designated File Types list, and if a match is found here, then it blocks execution, even if the executable that actually executes the file is allowed, like what happens with cmd.exe (which is allowed, because is in Windows dir) and *.bat files which are blocked execution, because are part of the Designated File Types list.

    Now, if one removes *.bat from the Designated File Types list, *.bat will be allowed execution via cmd.exe, and because cmd.exe is allowed execution in the first place, because it's part of Windows dir, which in turn everything over is allowed.

    If *.bat is allowed to run (Removed from the Designated File Types list), SRP will then check if the executable (cmd.exe) that actually executes the *.bat file is allowed.
     
  20. wat0114

    wat0114 Guest

    @m00nbl00d, I think Pedro means, hopefully I understand properly, that SRP doesn't look at the file extension, just as AppLocker doesn't either. He's suggesting change the extension on procexp.exe to .bat so it is now procexp.bat. SRP will block it because the very context of the file is a binary executable. Is this right Pedro? I remember Windchild explaining this about AppLocker a while back.

    BTW, I'm only asking because I want to fully understand, not to try and prove anyone wrong . This has been an intriguing thread with lots of interesting viewpoints :)
     
    Last edited by a moderator: Nov 11, 2010
  21. Pedro

    Pedro Registered Member

    Joined:
    Nov 2, 2006
    Posts:
    3,502
    That's the point ain't it? So why is procexp.bat blocked? Because SRP is not just by file extensions.
     
  22. Pedro

    Pedro Registered Member

    Joined:
    Nov 2, 2006
    Posts:
    3,502
    wat, yes that's what i'm saying.
    In fact, and i can't be certain since i'm not in Windows, i'm surprised the batch file executes at all even if you remove .bat from the list.
     
  23. wat0114

    wat0114 Guest

    Hi Pedro, thank you for clarifying. I tried your experiment and it works exactly as you suggested; procexp.exe renamed to procexp.bat does not run (blocked by SRP) even with the BAT file type removed from SRP's list.
     
  24. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    Yes, I'm aware of that. You can't modify the nature of a file. An *.exe will always be an *.exe.

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

    So, if a file type is listed, then SRP will apply the policy. This is what happens to any of the file types present in the Designated File Types.

    If you remove a type, the rule/the policy is no longer enforced, allowing the file type to be run/to be executed.

    This means what?
    Does it mean that the file types in the Designated File Types are being ignored by SRP o_O
    Or, does it mean that SRP verifies the Designated File Types to know whether or not these file types "wanting" to be executed are being blocked o_O

    From what is mentioned in what I quoted, the latter makes more sense, no?
     
  25. wat0114

    wat0114 Guest

    Hi m00nbl00d,

    please see this thread, and check Windchild's posts 2 & 4, especially 2. He explains why file extensions aren't simply checked by AppLocker - and SRP - for that matter.
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.