the future of SRP: AppLocker

Thank you both Sully and Lucy! I think I can fix it

Great idea. However, for now I will probably go with your point #1 just to keep things simple for myself.

I saw that and will have to set aside some time to go over it thoroughly.

Admittedly, up until recently I was loath to accept this SRP idea, but I now see it as probably one of the best and certainly most efficient steps to secure a computer.

 

Fixed and working as intended after setting D:\Program Files\* permitted path rule Thanks again for the help!

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

according to MS there are pros and cons to including DLL checking:

DLL Checking
A program, such as Internet Explorer consists of an executable file, iexplore.exe, and many supporting dynamic link libraries (DLL). By default, software restriction policy rules are not enforced against DLLs. This is the recommended option for most customers for three reasons.

• Disallowing the main executable file prevents the program from running, so there is no need to disallow all of the constituent dynamic link libraries.
  
  CONS
• DLL checking results in performance degradation. If a user runs 10 programs during a logon session, the software restriction policy is evaluated 10 times. If DLL checking is turned on, the software restriction policy is evaluated for each DLL load within each program. If each program uses 20 DLLs, this results in 10 executable program checks plus 200 DLL checks, so the software restriction policy is evaluated 210 times.
• If the default security level is set to Disallowed, then not only does the main executable file have to be identified to allow it to run, but all of its constituent DLLs also must be identified, which can be burdensome.

PROS
DLL checking is provided as an option for environments that want the highest assurance possible when running programs. While viruses primarily target executables for infection, some target DLLs. To ensure that a program has not been infected by a virus, you can use a set of hash rules that identify the executable and all of its required DLLs.

Any thoughts on this and do you guys feel it's better to include DLL checking in SRP at the expense, no matter how severe, of performance?

 

I have read articles espousing both sides of dll checking. Near as I can tell on my main machine, there seems to be no lag or other speed anomoly. Granted I am admin using SRP so perhaps it is more noticable in a LUA.

BTW, are you anywhere near Cardston, Lethbridge or Pincher Creek or somewhere that far south?

Sul.

 

Microsoft is just being Microsoft with those articles. If you're running SRP on a system built in the year 2000, there may be some performance loss with DLL checking that you might even notice. But if you have a relatively new system with decently powerful hardware, you'll never notice anything at all, probably not even if you try your best to measure any slowdown with testing software. I've been running DLL checking all of the time, and have never seen any slowdown at all. So, you can forget the performance aspect - performance loss is a non-issue.

Then on to the second "con" listed by Microsoft, the added effort of listing all the DLL files your programs need in the SRP rules. That is a non-issue, too, because the SRP default rules already allow pretty much any DLL you would need, if you just install stuff in Program Files. The default rules allow anything in the Windows and Program Files folders, including all DLL files. So, you will not need to make any additional rules to allow DLL files, unless you have needed DLL files somewhere outside Windows or Program Files folders. If you do, then just make the proper path rule. Say, if you for some reason install your software into D:\MyStuff, just make an unrestricted path rule of D:\MyStuff in SRP and all the DLLs will be allowed, too. Keep in mind, though, that for SRP to actually be fully effective you need to run as a limited user, and make sure the limited user does not have write access to any of those folders that have been made unrestricted in SRP.

So, in short, go ahead and enable DLL checking. There are practically no downsides. SRP is easy to bypass if DLL checking is disabled. For example, even Conficker would walk right past SRP if DLL checking was disabled.

 

That is a problem when an application stores dll in the same folder where it writes datas sometimes coming from outside. Then you can't always restrict write access. As you allow execution there. You might as well permit execution of downloaded malwares...

I'm thinking of Chrome...

 

Okay, I'll keep it on DLL checking, and tbh, I have not noticed a difference in performance either, even on the much older PII machine. Thanks for the advice!

Absolutely, I've never used my admin account for anything but installation of programs and other miscellaneous maintenance purposes. Everyone in this household runs under limited accounts, though for several years I had them set up as power users with certain restrictions on key directories. This latter practice was done for purposes of allowing a little more freedom, but I've since realized it's not necessary for most typical needs.

No, Calgary.

 

Yes, you are right. But then, I would never use such applications, and therefore would not have this problem. Because...

Applications that require write access to their installation folders after the installation just so that they can run properly are applications that are unaware of the Windows NT security model, and do not even attempt to conform to the "rules" of said security model, or attempt to work properly on limited user accounts. The whole idea in Windows NT is that applications are to be installed in Program Files, where their files are protected from tampering by non-admin users, and any configuration or other data for the applications are to be stored in each user profile's Application Data folder where the users can have write access to it. Any application that does not conform to this is pretty much "software for Windows 9x" and a dinosaur of the old, bad times. Or in less fancy words, such software is pure crap and should never be used by anyone, unless their very lives or wallets depend on the use of that software.

Now, some might be inclined to say that they have an otherwise good software that they like, that just happens to have this one security flaw of requiring permanent write access to its installation folder. But those people should consider this: if an application has that flaw, it was written by people that obviously either don't know or don't care about the NT security model. Do we really think people like that can create safe code? Do we think that their software does not also have about a million other security vulnerabilities that we just don't know about yet, and probably the manufacturer doesn't, either?

In short: we shouldn't use crappy software.

 

Perhaps you should temper that hard-line opinion with a pinch of reality lol.

Don't get me wrong, I agree with your stance. However just because you have made a program that houses all needed files in it's own directory rather than spreading them throughout 'userland' does not mean EVERY program that does this is somehow crappy, nor that the author is a crappy code writer.

I take as an example the program SpeedFan, which uses configuration files located with the executable, of course in the program files directory. As a User, with no modify rights to program files, Speedfan does not work as it should. But in admin account, or modified User account, it is a very handy program. I would argue the best in class for fan controllers. I don't see that as a program I should worry about being compromised, nor do I see the fact that he did not use 'userland' as an example that he is making crappy code because he is a crappy coder. Actually for someone to provide a free application, updated as often as it is, and works on nearly any machine, and dealing with very low level stuff, I think he is a very good programmer. True, it would be nice for it to work in User account properly, and perhaps there is a way to do it. My only point is that your hard-line approach fails to take consideration into play.

As they say a grain of salt with everything lol. But do you really not use ANY program that fails to meet your strict criteria? BTW, this is not a debate nor is there an implication of such. It is that I can think of many very nice programs that would fall into your 'crappy' criteria that are very well made programs and most definately not crap at all.

But SRP or AppLocker has what bearing with this direction of thought? lol.

Sul.

 

True, but the authors of these apps are responsible to a high degree that most Windows users don't even think about LUA. I mean the Windows security model was introduced with NT. That was ages ago - but the author of SpeedFan and others are not yet able to write their apps the proper way. That's ridiculous. I agree with Windchild that one shouldn't support such people. If they had changed their attitude in the past the malware problem for Windows wouldn't be as big as it is.

 

Well now, it may be a little on the extreme side of things, but it works perfectly well in reality, as long as one understands what it is about. You are of course right that not all software that stores all of its files from executables to config files in the installation folder is crappy. That rule only goes for applications that are supposed to work in a LUA environment. And when I say "supposed to work", I don't mean "the coder wants it to work", but rather that the application contains no functionality that it could not provide without admin privileges, given better coding. There are, of course, many things that you need to be admin to do.

I don't know the program, but anything that involves controlling hardware is pretty low level stuff, and often requires admin privs. I wouldn't be surprised if SpeedFan installed a driver to do what it does, and that requires admin privs. No way around that requirement, really. That in itself is no reason to not make it work with LUA after an admin has installed it. If the coder chooses to make it LUA-incompatible by requiring write access to installation folder, then you've got a case of lazy coder. Lazy coders may not automagically produce crappy code, but the risk is certainly higher, and in any case the code will lack features that it could have had if it were not for laziness. And programs like this are largely the reason why so many people think LUA is too restrictive: because lazy or ignorant coders code their apps so that they do not conform to the NT security model.

It depends. I use plenty of stuff that can't run in LUA, and for those, it doesn't rightly matter where they store their config files - installation folder or otherwise, the program would still never work with LUA due to what it does (like dynamically load/unload drivers etc). But for the software that should work in LUA, I only use stuff that saves its data where it is supposed to, and that is not in the installation folder. So, I figure that the answer is "yes, I only use programs that meet my strict criteria." There are a lot of programs in the world, and I've never seen any program that both does not fit my criteria and does not have an alternative that provides the same functionality without failing my standards.

Well, obviously Lucy already answered that. SRP and Applocker can use path rules to allow or deny execution. Any application that requires write access to the folder where its own executables are causes trouble with SRP for this reason: if you allow the path to the installation folder, you not only allow the legit executables in that folder but also any malware that feels like writing itself into that folder. This of course can be countered by more complex rules, but that's the point - it is inconvenient compared to wider path rules (folders as compared to single files). Not a big issue for SRP, really, but a much larger issue for security in general. If limited users can write in the installation folder, they can overwrite the executable with malicious code. And the next time when an admin runs that file, the system is owned. Bad. Well, that's technically only true if the executables in the folder allow LUA full write and modify permission. But that is rather often the case, I find. Seldom do those who can't be bothered to save config files in Application Data bother to set decent file permissions at least for their program's executables. Usually, it's just Everyone - Full Control.

 

Yes, exactly! That is really the most important point of this, and what I was trying to say in a very long-winded way.

 

lol, to true really. I would prefer that things like SpeedFan or RivaTuner or Unlocker could operate in a LUA with no problems. I tell you though, in those 3 instances, SuRun or any other method just does not give the same results as being Admin. I utilize those 3 very heavily. There is just nothing like them, nothing even close for my uses.

What I am waiting for is a way for those drivers those program use to be able to be ran in LUA, but I don't think it will happen. Config wise, it is easy to set Speedfans parameters and then leave them. Of course for those who constantly tweak, erm, like myself, it is more of a pain really. RivaTuner is the best example of this I know of. I use this program all the time 24/7. Yet it has proved difficult to reliably use in LUA. I have made many different approaches, coded myself, that work, but things are always undependable.

Should I court the programmers to change? lol, I already have. Will they change? I can't say. But I do know that for myself, I am unwilling to go without them. I have taken a shot at learning some of that to code my own stuff, but honestly I just don't have the time to devote to it. Those guys who made those apps really impress me with thier knowledge in that area. It is a very intensive subject that low level hardware and driver stuff.

You know, I am all ears should anyone have any ideas on how to run in LUA while still allowing things like these to remain fully functional. I have certainly spent a lot of time trying to figure out how to do it. I mean, all the hacking and tweaking I do, everyday, I 'could' do from LUA. It might be a little more PITA, but doable.

You guys are right though, if everyone adhered (or was able to) to the limited user scheme, much of the issues of the day would be mitigated.

Truly, I absolutely love this forum. Especially threads like this one where you can share your thoughts and have others not develop some high and mighty attitude, but all help each other to build and learn.

Cheers.

Sul.

 

Do you all agree to say that M$ is heading towards forcing "lazzy" programmers to comply with the M$ NT or whatever in the future security model.

$ gurus like Mark Russinovitch emphasize so much on the fact that UAC is not a security tool, but rather a tool to have programms behave as they should, ie, functionning in a LUA environnment.

It rather disappoints me to think I should override basic yet powerful security scheme, in order to have a fan optimization tool run, whatever the beauty of the code, or the elegance and deepness of the programming. Thousands of programms use drivers and work under LUA. All Linux is based on this. So shall be it in a near future, if M$ succeeds in applying this commitment.

Yeah.
Some learn more than they teach and vice versa.

A learning fellow

 

Could it be that the problem is precisely UAC? The main goal of UAC is not security, but to provide LUA users usability, in order to perform certain tasks that, otherwise, would have to be done from within an Administrator account.

For example, if we disable UAC and use a LUA, things requiring Administrator privileges wouldn't function.

Now, as we know, Windows automatically creates an Administrator account. So, UAC or no UAC, users will manage to use all they want.

What if Microsoft would have implemented the automatic creation of a LUA, and there wouldn't even exist UAC? I hope I'm not saying any barbarities, but, I do believe that most users don't know the difference between one and the other. For them, an account is an account. They just want to use their applications properly.
Now, if we consider the scenario above (LUA and no UAC), then users would see that some of the applications wouldn't work.

Facing this situations, there would be three possible scenarios:

- Users stop using those applications

- Users complain to the programmers of those applications, that their creations do not work and are totally crap. The programmers start making them work in LUA.

- Users complain, but the programmers tell them to use Administrator accounts, and even explain those users how to create them.

Could I say we're pretty much on the hands of the programmers? If they decide to the right thing and make their applications work properly under a LUA, then we applaud. If they all had decided not to care and keep developing as they were, would we just stop using applications? What if every programmer was that short-minded? (Let's forget Linux. )

I guess that the resolution lies between all parties - Microsoft, users and programmers.

Microsoft started to make the first steps.
Users - and I make my best to open the eyes of those I can - are more aware of the dangers of Administrator accounts, and move to LUA. If all users say - Enough! We want to use LUA and want the applications to work

Then...

Programmers - they need to keep with the pace, if they don't want to stay behind, and loose business.

Maybe I'm seeing this all wrong, but I just finished dinner and digestion isn't over.

 

Yeah, Microsoft is trying to force programmers to make better, more security aware code. I applaud that, but I also think they could and should try even harder.

If I was them, I might even set up some kind of public Hall of Shame and just plain and simple call anything that doesn't work properly in LUA even though it should "potentially insecure software that we cannot recommend" or something like that. Pretty harsh, and not very diplomatic, and I'm sure there are better approaches, but the point is that still much more could be done than just UAC and associated changes.

For some other extreme measures, force people to make a real limited user account at Windows install, and force them to read instructions to use it, and then later annoy them at every turn whenever they're logged in as admin so that they will also use the real limited user account and not the admin account even when the admin account is protected by UAC. One particularly evil but simple trick would be just making the GUI ugly as hell when logged in as admin and impossible to change: big red warning background complete with "You are logged in as administrator - this account is only for system administration tasks. Please log in as a limited user for a secure Windows experience." or something similar that one cannot change. Make it so that whenever a browser or email client is opened under an admin account, Windows takes over the screen and says "Don't do this or you will get pwnd by some Kreplakistanian scriptkiddie." and make it impossible to disable or avoid in any way. Of course, none of these annoyances should go for the real admin tools: group policy editor and other admin tools should work without any extra annoying prompts, but anything that doesn't need admin should be made incredibly annoying to run as admin. In short, just make using an admin account plain hell until people will literally want to run limited user accounts just to get rid of the nuisance, and will only reluctantly log in as admin to do the real admin work when absolutely necessary.

But it's not up to just Microsoft. We, the so called educated users, should make some noise, and request, suggest and occasionally demand that programs conform to the NT security model and work as they should in LUA. I'm doing this all the time. Whenever I see an even remotely interesting program and discover it has LUA bugs, I complain, loudly. Sometimes it works!

 

Hello Sully,
You might take this issue over to the SuRun English forum and ask Kay. I never tried Unlocker with SuRun before, maybe I'll try it.

 

It is unfortunate, but Unlocker requires debug privelages. You can use the GPO to give Users debug privelages, but it is not a very secure thing to do. I am always traversing directories, and it is often then when messing with things, a file I wish to move/rename/delete is locked by a process. Unlocker is what I find the easiest to close the handle down and give me control back, rather than waiting or rebooting.

I doubt there is anything that can be done, as there should not be a reason to give debug rights to anyone but admin.

Thanks though for the insight.

Sul.