For Users of Software Restriction Policies

Sul,

not running Windows with LUA (or UAC) and using PGS as admin instead is basically a DropMyRights approach. In previous posts (here and here) I mentioned some important disadvantages. They can only be prevented by a combined LUA/SRP approach, IMHO.

 

Some really interesting stuff..

Windchild, you say the Microsoft has piles of documentation for SRP etc. I personally found Mechbgon a bucket load easier to follow (and rationalise) than MS's "monotone" efforts on this.. If MS have any ambition to address a larger market, imho, they need to think about how they target that larger audience.

Re HIPS, I would have thought this increasingly can work easily for less sophisticated users, but with products where the software interface provides a stronger emphasis towards applications say rather than dll's etc.. I know I am being somewhat simplistic here, as regards the possibilities of such threats and how they arise, but if nothing else, that is a first step and one that less technical users can more easily relate to..

One thing I found interesting here about LUA (or UAC in Vista).. With Vista, the online MS documentation (on set up etc) gave a strong pointer right from the start to use UAC and set up a Standard user (more so than with XP if I recall correctly).. In other words, it really did take minimal effort (and when I installed the Vista laptop, I knew NOTHING about Vista at all - I had been using other MS versions, and had not personally used limited user accounts at all since Novell)... what I am saying is that putting in UAC by default might not be that problematic for users provided there is a strong enough lead / default from MS. MS might even sell the OS with two accounts (rather than one) set up by default (one admin, one standard user), with some very simple instructions for explaining the difference, installing software, backups, updates etc..?

 

I guess the primary purpose of UAC is to make non well-designed programs, that is the ones constantly requesting credential, so annoying that it will enforce programmers to design fully userland based programs. And that is a huge task towards security in itself. Credentials requests would decrease drastically and eventually when a users accidentally meets one, it would really make a meaningful alert...

I agree with the difference between UAC and SRP. SRP is definitely an admin tool. At the end, I am not sure that any of the two can even be considered as a security tool...

 

Yeah, Microsoft does have a great bucketload of docs for SRP, and just about everything else. For example, if you know nothing about how file permissions work, you can just fire up the help files built into Windows, read, and then you'll know a lot. All it takes is thinking (and I have seen some actual, very novice users understanding it all perfectly after I convinced them to RTFM - the hard part is making them do the reading). Microsoft does, being a software company, have a habit of writing in a "technical" way, giving lots of details (that are actually useful, even necessary, to folks like system admins, who might actually read the docs that novice users do not bother to read very often). As you said, a lot of it could be said in a much simpler way that is easier to understand, perhaps. But then, that would leave out the details that some readers actually need (an SRP example: how rule precedence works). Microsoft has to write in a way that includes enough detail for even the most demaning reader that really needs to know a lot about how that stuff works, so they do it. The result is documentation that offers a wealth of information, but isn't necessarily a quick or easy read.

I don't see how Microsoft could really avoid this. Their assumption, and I think it is the right one, is that the average home user will not be interested to learn and understand SRP no matter how simple the documentation might be to understand - and those users who are interested in understanding it, can do so by just reading the documentation meant for admins with a little thought that every normal human is capable of. This is reflected in how Microsoft leaves out the complex security features in Home editions of their software - no SRP or Security tab in folder/file properties on XP Home, for example. Perhaps this assumption and policy will change in the future, perhaps not. For advanced features in general, though, it is rare to see simple documentation that is worth anything.

Of course, those enthusiasts that write their own How-To guides are doing a service to those that do not like the more exhaustive documentation offered by MS. That is, as long as the How-To guides have correct information, which isn't always the case. For example, in spite of others advising to the contrary, I would really, really not ever recommend anyone running XP Home to try to hack SRP to work with it, using the registry. I'm not saying that you shouldn't do it if you really want to - but I am saying that if/when something breaks, there's only one person to blame for it, and that person isn't Bill Gates.

Yes, it's an enormous task to get developers to make software that works properly in LUA, and Microsoft has been trying a long time. The problem with using UAC or similar methods to do that (which I don't think MS was trying) is that instead of making people ask developers to code better apps, UAC makes people ask other people how you can disable UAC so it finally shuts up.

 

Pretty Good Security, aka PGS, is a huge step without any user hacking, to have it in a simple way.

What is done with the tool can be undone with the very same tool in a simple manner.

 

I have not tested that tool, but in any case, nearly anything is an improvement over registry editing, where the nearly inevitable novice user error at some point will change x into y when typing one of those lovely long strings that seem meaningless to most people, and then things will start acting up. I think I'll go learn that PGS thread I see in the thread listing now.

 

In Win2K years ago, I thought, Why can't I run as an Administrator if something would alert me when attempting to install w/o my permission? I discussed this with some friends, and learned about FreezeX - predecessor of Anti-Executable (AE). I discovered similar products: ProcessGuard, Executable Lockdown, and others. I eliminated ProcessGuard (PG) because in thinking of using something like this in home situations, I wanted the alert to be Default-Deny. PG displays a prompt for action:

​

AE's alert denies by default:

​

My reasoning was this: if something attempts to install unexpectedly, it should be denied by default. When choosing to install software, a simple click permits the installation and the new executable is then added to the White List.

There are no rules to create. No nags during normal operations. I've used this solution successfully for many years.

The situations with codecs, update_flash and the like, should also be Default-Deny on the part of the user. That is, to quote Brian Krebs in a security article, If you didn't go looking for it, don't install it.

Instilling this user-decision policy comes through user education, as has already been mentioned. I've never had a problem getting people to accept this. I like to show screenshots, which helps them to understand. Do you remember Koobface that made the rounds on MySpace?

​

I just don't think computer security for home users has to be complicated.

In Enterprise situations, it is more complex, and I think SRP is an ideal solution, as illustrated by Tom in the ISC article I linked in my first post.

----
rich

 

You're right, of course - security for home users or small business users doesn't have to be complicated at all. It does require users that are willing to listen and learn, though, and not all users are like that - some are exactly the opposite. I seem to have bad luck, and frequently run into those users who are very good at resisting good advice.

I like the way you phrased that the user should also be in a mindset of default-deny. That is how it should be. Do I need this? Do I know it is safe? When in doubt, say no.

Running as admin I don't like, even with anti-executable products, simply because even whitelisted programs can cause trouble that a LUA might be able to prevent - you don't need to execute anything unknown to land in some kinds of trouble. I have seen system files accidentally deleted or overwritten by various buggy software that would have been whitelisted - and all could have been prevented if the user had been running as non-admin.

I remember Faronics' AE, but now the 3 version isn't as good as the old version 2, and there's still the issue of many people wanting to use something free (after having paid a lot of money for a computer and Windows, it is pretty understandable). SRP fits in well there, as long as one has an OS that supports it. The feature set isn't the same, but both can do the job.

SRP does require care to make it more difficult to bypass, especially if one is using it to protect against local users screwing around, but that can be considered part of the learning experience, and it isn't very difficult if one has a basic understanding of how file permissions work in Windows.

 

I love this place. You always get different view points and thoughts, which only help refine your own. If you are open minded anyway.

I used to sort of have a love/hate thing with MS. But as time goes by and I help more and more peeps, I see things differently. If I owned MS, I would have done the same thing I think. Because as a business, you make the most money by targeting the largest market. And the home owner is by far the largest market. World wide. I don't know what % of homes have computers, but I bet it is pretty high in more developed nations. And I would bet that the MS moniker is on a very high % of them. So from a business perspective it meant allowing a sort of ease of use that comes from being an admin, especially for those who know nothing.

Arguably, they could have started with more security non admin scheme. But would new consumers be as apt to jump on board when they know nothing? If all they have to do is click or double click, it sounds pretty easy. For a business that wanted to make money, they made the right choise.

Now however, we are all in the same pickle. The same peeps who know nothing have become the target, which even the knowledgable now must have to deal with. I know, users just don't want to take the time to learn, many of them. Having classes or being a tutor or adopting one, yes some will because they have the interest. But there is a large number that want to learn how to use certain programs, but not the OS. It is just not what they are interested in. These are the ones I seek to help the most. I know many of them.

@TLU, I know what you speak of. I agree in most instances about that. However, I am deep into the bowels of some syntax that is dreadfully hard to find values for, that I think will make it super duper easy to change all of that. And customizable for a script to build on the fly as well.

Peeps who use LUA, what do you do? I know, from business end, it is the only answer. For gamer or surfer or photo editor, it is most likely answer. Those of you who use it, what do you do? I always wonder how you do it. For me, if I am on the computer, I do one of three things. Occassionaly play games, often browse looking for answers to code or something of that nature, or I am coding/hacking/playing/breaking. I use regedit all the time. Command prompt, batch, .reg, tools like secedit or scripts that need admin. I am always always always tearing into parts of the OS that need admin rights. I have tried SuRun and LUA. My use, there is just no way. I need debug rights. SuRun is unable to give that to a remembered application. I need low level access. Point is, for my home computer, I just get bogged down when using LUA.

Because I know so many who just plain could care less about security or thier computer in general, but just want it to work, I focus a lot on how I work, how I can use security that won't interfere with my 'playing', that I can use everyday, that I can setup, but also, that I can put on thier system. I don't care if they know how or why it works. Only that they follow as few simple instructions as I can give them. I find they can learn new methods of the same old thing, so that is why I strive to create some easy formulation of obscure security for admin, that is pop-up free, config free for them and requires very little in way of thier interaction at all.

SRP is a big step on different levels. Providing other means have been addressed that could cause issues, as Tlu refers to. So would LUA if you could get them to learn something, devote some time to it.

With any luck, in the next few weeks I will solve my current dilema. If it works, I will incorporate it into PGS as a seperate utility. I will take ownership of everything and give it to admins, both files/directories and registry keys. Created objects or containers or registry keys will inherit this ownership. I will selectively allow GW,GR and GX manipulation on files/directories and registry keys. All from one file and one command line tool, included with xp pro and vista upper end versions. I will be able to create or modify any registry key of any value (I think) even 64bit OS. However, as is usual, MS provides such crap for thier docs on some things it is maddening.

After this is achieve, I sincerely hope to present a security scheme, that is both easy for those who know how to, to configure it, and also easy for those who don't know a thing to use it. Only very minor tweaking of how they currently do things should be required.

While I dearly love these kinds of discussions, I am frankly tired of the same old song and dance with end users. You and I, we can do what we please. We are motivated to find solutions to fit our desires. Others, they need constant hand holding, and I mean to put an end to that for those whose hands I have to hold.

What a great thread.

Sul.

 

" Hi all, thought this might be of interest "
.

An introduction to ACL based security and the Windows Access Control model.

Background

One of the original design goals of Windows NT was to provide a layer that can implement security for the operating system. The way Windows NT implemented security for its objects was through the Access control model. Even role-based security and the .NET classes could not replace this ACL-based security model. ACLs are far too embedded in the NTFS architecture objects, and the registry was to be rendered obsolete (so much so, that .NET v2.0 had to relent and end up supporting the ACL model too).

To start off, I will describe the different types of structures you may meet when programming for access control. This article is intended for all programmers (this part contains no code, just structures and programming concepts).

http://www.codeproject.com/KB/winsdk/accessctrl1.aspx

 

Nice. Suppose you want to set an ACL but have not any ACE's you wish to change. For example, you wish to take a file, mydll.dll, which has current ACL of D: (A;;GRGX;;;BU)(A;;FA;;;BA). Maybe this was a file that has no owner, or maybe it was created by User1, who is an Admin and a User and they are the owner. How would you construct an ACL with no ACE's, like this O:BAD: where you might or might not use : P/:AI/:AR/: PAI/: PAR/: PAIAR. So the result, is not to remove the ACE's, but to change the ACL (in this case the O:BA flag) and retain any ACE's. As well, suppose you were using registry, where instead of FA or GR you would use KA or KR. Objects, containers or regkeys, in each instance, how would you create an ACL that retains the ACE's but also propogates the inhertance to all children (of each type). Again, this is without changing the rights indicated by the ACE's.

I think you will understand this SDDL it seems. I hope so anyway.

Sul.