The irrelevance of Applocker / relevance of SAFE admin tweaks

Indeed! There's still a lot to learn! I have a long way ahead of me. ILs have a lot potential.
I can't possibly understand why Microsoft decided not to take it seriously in Windows Vista. As for Windows 7, they just didn't take it out. It doesn't hurt having it, I guess.

 

Oh, I think they did take it seriously. They developed (or modified) much of the OS around it, including their browser. I don't think they thought about the scope like we are though. It is similar to SRP or Applocker.. it has merit but is just complicated enough to never be mainstream for average folk.

They stuffed it into the SACL, which really is a good place for it as things currently stand. I only wish it were more like DACL in behaviour, it would be much more robust.

Nothing I like better than making something do what it was not purposefully meant to do. ILs hold more promise for me than SRP did, I think

Sul.

 

Things get weirder.

I decided to test again, and I created a new folder with a Medium IL. I made a mistake and instead of setting it to Medium, I set it to Low. So, I took a step back and set it to Medium. The installer.exe, which previously was in the Low IL Downloads folder, won't start in the Medium IL folder. I changed the IL to High and it starts. I changed the folder to Medium IL again, and now the installer.exe starts.

I tried again, and this time, I did things right. The thing is, even in the Low IL Downloads folder, the installer.exe will start! Very odd. Reason? The object is not inheriting the IL of Low from the folder, despite the fact the folder is set to do it so, when applying icacls folder_name /setintegritylevel (OI)(CI)L.

I opened the web browser, and then copied the path of the installer.exe, placed on the Desktop, and saved it to the Downloads folder, which is with a Low IL. This time, the behavior is the expected one: the installer.exe fails to start.

I placed the Desktop installer, once again, inside the Downloads folder, but it won't inherit the folder's IL of Low.

ILs really are a lot of fun to work with.

Well, I tested it again. By placing the installer.exe inside the Low IL Downloads folder, the *.exe file won't inherit the folder's Low IL.
I haven't tried this approach before now. After all, that's not the purpose for the Downloads folder. The purpose is to keep whatever is downloaded by the web browser with a Low IL, and this is achieved.

I can't say why, in my case, it won't inherit the folder's Low IL. Any object, manually placed over there, should inherit the Low IL.

More info: I changed the policy to NoExecuteUp using chml. Then, I placed the installer inside the Downloads folder, and now it won't execute.
Then, I placed the installer.exe inside the new folder with a Medium IL. The *.exe sucessufully runs.
This is the best approach, indeed, for those stand-alone applications that do not require to be installed, and that do not require Administrator rights to work, or that will install to user space.

I'm guessing that the reason why the installer.exe fails to run, when saved by the web browser, is due to the fact that the web browser runs at a Low IL (Chromium, in my case.). Despite the fact that not an Explicit Low IL, otherwise things, probably, wouldn't work as they should. The same reason why IE with UAC doesn't run with an Explicit Low IL. The broker process always runs with a Medium IL.
Could it be that having the web browser (Chromium) working the way it does, plus the Downloads folder with a Low IL, is different from placing an object directly into the Low IL folder?

I don't know why having a folder set to Low IL with a default policy of NoWriteUp won't stop the installer.exe from starting, if I manually place it over there. It should, but it doesn't, in my case.

 

I know exactly what you mean. There are more than one factor at play, but it should all come down to understanding how it really works, then working up from there. That is my goal, to truly know all the options and how they should work. Then it might be possible to understand how other elements effect things.

Sul.

 

Sul,

Would be great when you can assign desired rights level without needing to process all objects individually

Regards Kees

 

A brief recap of Integrity Levels for anyone interested.

Integrity Levels matter a lot to the OS. In fact, they are now as much a part of the OS as the rights applied to every object. There are only three Integrity Levels that you should be concerned with. They are Low, Medium and High. If you think of them in terms of user accounts, High would be an Admin, Medium would be a User and Low would be a guest. The Integrity Level that a process has directly influences what and where it can modify, write, execute, read or delete. Almost exactly the same as different user accounts do.

Integrity Levels follow a basic set of laws. There are some obscure actions as well, but they don't concern normal usage. I will attempt to describe the Laws of Integrity Levels:

( here we assume you realize what a parent process is, and how it creates a child process )

Things are a little different when there is an Explicit Integrity Level assigned to an object. These are the Laws of Explicit Integrity Levels:

When using Integrity Levels with objects (files) the behavior is obvious. You set an Integrity Level and it applies to that object. When using Integrity Levels with containers (directories or folders) the behavior is somewhat different. These are not laws really, just behaviors:

Explicit Integrity Levels applied to directories only seems to have little effect. The real benefits come when the directory uses inheritance and passes its Integrity Level on to the objects within itself.

It should be noted that depending on what Integrity Level you use, and where and what you are attempting to do, you might be denied access when you don't expect to, and allowed access when you don't expect it. Integrity Levels honor the DACL (Discretionary Access Control List) and all ACEs (Access Control Entries) within the DACL. In laymans terms, if a process is running at Medium Integrity Level, for all intents and purposes it is behaving as a User. In this case, the process would be denied rights in Program Files and Windows directories that same as a User would.

Sul.

 

Now, lets discuss how one might go about restricting something like a "downloads" directory.

You could use a deny execute ACE on the directory, essentially denying any execution by anyone. This definitely works.

But, lets push past that and learn how Integrity Levels might be used. There is no compelling reason to do so, or is there?

Assume the browser is the program that we want to restrict. We want to deny it the right to execute in the "downloads" directory. Of course, it is very handy if the browser were told to only save files to that directory, wouldn't it.

Assume as well that the browser runs at the Low Integrity Level. It is restricted whether by its own design or one that we have force upon it.

There are a number of things we could do. But first and foremost, we must decide how to handle the "downloads" directory. Since the browser will run at Low IL, lets set the "downloads" directory to be a Medium IL. In this manner, we don't give it full permissions, and actually we will be 'forcing' it to only have the rights of a regular User.

This by itself doesn't do much. The default value is simply Medium IL with a NoWrite for lower Integrity Levels. But what does that mean? Well, it means that the directory "should" disallow the browser (running at Low IL) from creating any files in the "downloads" directory. Is that what you want? Maybe. (note, I have yet to confirm that will always be true, it is just how it 'should' be).

So lets modify the IL of the "downloads" directory, and remove the NoWrite flag and instead use the NoExecute flag. Now, our browser, running at Low IL, is allowed to write all it wants, but cannot execute. Is that what we want? Maybe.

But what happens if you want to browse the "downloads" directory and execute something with something other than a browser? Perhaps it is Q-dir and Q-dir is running at Medium IL. No problem should be posed, Q-dirs Medium IL will easily execute the forced Medium IL files in the "downloads" directory.

But what if Q-dir were running at High IL? Again, no problem because the items in the "downloads" directory are being "forced" to start at Medium IL. But is this good?

Think for a moment. If a Medium IL is the same as being a User, essentially, is it good? It means that whatever is executed can execute, but cannot do things that a User could not. It cannot install to c:\Program Files. It cannot modify/create in c:\Windows. Maybe that is what we want.

But what about when an Admin process runs it? Don't forget, the items in the "downloads" directory are forced to start at only Medium IL. They will start at Medium even if a High IL (admin) process is the parent.

So, we have denied a Low IL process such as a browser from executing in the "downloads" directory, and we have ensured that anything that does execute will only do so at a Medium IL, or the same as a User.

But what if you want to keep those files or actually execute them with Admin rights? Ahh, this is where Integrity Levels have a weakness. In order to execute these files as an Admin, thier Integrity Level must be changed or removed.

One way to do it is to move them to another directory that forces them to have a High IL. Perhaps not the best solution, but it might be if you like that. Another way is to simply copy the file to another location. Copying removes the Integrity Level. Actually, it just doesn't use the original IL at all, it ignores it when it creates the copy. If you copy it into a directory that is also forcing inheritance onto its files, then you will obviously not end up with no IL, but with whatever the directory is told to give it.

One could also, if they knew how, just remove the Integrity Level from an object. This is perhaps not as ideal as copying it, but might be faster if the file is very large.

There you have it. A few rudementary ideas on how to deal with a "downloads" directory in some interesting ways. Are they better? Or worse? Eh, who knows really. Integrity Levels themselves are quite confusing until you get the whole picture. One thing is for sure, they are given more importance than the DACL, which means, umm, well gosh darn it, it means something

Sul.

 

Sully,

I can go with a no execute up option of the download directory, providing the temp folders will also have no execute up (IE and Chrome also have access to temp folders, and I would not go intp theoretical sitautions where a dropped process in the temp folder spawns an exectable in the download folder, therefore the remark for temp folders, to be sure).

Reason for me to set a deny execute with ACL is dead simple: for the average user it is clear that nothing can execute. My friends running with this setup have to move an executable to their desktop or something.

So while for security the no execut up is sufficient, the (maybe redundant) deny ACL is for simplicity reasons. AppGuard also applies a simple deny execute of the user space (they have usage simplicity as a design principle)

Regards Kees

 

@Sully and Kees: check out RunInsideLimitedJob.

 

Thanks,

Chrome's sandbox uses this: lowers the IL, creates a restricted token, assigns a job object (with max handles) and allocates it to an alternate desktop.

another option is https://code.google.com/p/ulimitnt/wiki/Readme

I have been looking on this to (in combination with a restricted SID)
SECURITY_RESTRICTED_CODE_RID, you'll find:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/sid_strings.asp

http://msdn.microsoft.com/library/d...s/secauthz/security/createrestrictedtoken.asp

 

This is what I want!
by the way what is Q-dir?

 

Q-dir is my chosen file explorer for windows 7. At first it was just "ok". But now, after using it for some while, windows explorer is slow, slow, slow.

http://www.softwareok.com/?seite=Freeware/Q-Dir

Sul.

 

Sul,

Would you think about adding this policy setting as an extra option to Safe-Admin

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"ValidateAdminCodeSignatures"=dword:00000001

This allows only signed executables to elevate


Possibly an option to virtualise browsers and email. Works flawlessly on my Vista x32 setup see https://www.wilderssecurity.com/showthread.php?t=282550

Regards Kees

 

Here are some current screenshots of the latest design changes. Seeking to simplify the UI more. Less choises for in-built options. Some customization, but on a simplistic level.

http://mrwoojoo.com/safe_admin/SA_alpha5c016.jpg
http://mrwoojoo.com/safe_admin/SA_alpha5c017.jpg
http://mrwoojoo.com/safe_admin/SA_alpha5c018.jpg
http://mrwoojoo.com/safe_admin/SA_alpha5c019.jpg
http://mrwoojoo.com/safe_admin/SA_alpha5c020.jpg

Comments?

Sul.

 

I would noy use the term FIX your problems: what are you fixing?
a) using the user specific values OR
b) change the default directories of f.i. ff?

Show them what the action does: Apply your values?



Why is there a Remove and apply in the defaults, just a greyed "Apply default values" button would do, since rules can be set/edited in the custom rules (don't mix functions = KISS)

Complements with the Wizard implementation.

 

Well, the concept of KISS is actually quite hard to achieve with such a tool. We are taking advanced features and trying to let it be used by novice users.

When SAFE is supplied with default values, it provides the likely files and folders needed for each program. For complete novice use, if the paths don't exist and the registry has no values either, the choise is left to either do a recursive search, fix the problem or stop processing that particular component.

I don't want to create something that does a recursive search, nor do I want to just stop it. So the obvious choise is to somehow "guide" the user to fix the issue. Whether "fix" is the best term is debatable I suppose.

In the first TAB, I hope it explains in KISS fashion what SAFE will do. No need to give specific details. Move on to start the process - which takes you to a wizard.

Wizard Sample 1 shows how a default set of paths might not exist, and how controls are greyed out. Sample 2 shows it correctly and how other controls are greyed out instead.

The remove button is to remove the SAFE settings for the specific item you have highlighted from the list on the left. Since each item that SAFE can work with may or may not be at the default location, when you highlight it, the right top shows what paths/files SAFE expects to find. The right bottom shows perhaps what the registry or a config file shows. I don't know that is a real example, just an idea for layout.

If you start SAFE the first time, the remove button will be greyed out. If you apply (or whatever term is KISS proper) the setting for the object, then of course the remove button is active and the apply is greyed out.

The hard part of this is how to handle, in KISS fashion, when things are not at a default state. If the user is novice, they might be able to understand that they use Firefox, and understand that SAFE doesn't find it where it expects to. My logic says that you need to fix this to proceed. How to develop an interface that makes sense for such a novice user is challenging.

This is hopefully explained generically in the first tab

This is the real problem. The custom values don't exist, and I don't expect a novice user to know how to use it. If they want to learn, then it works. If they know, it is simple I believe.

The whole point of the custom rules is to have an advanced area where you can do things your way. I would think that a novice user would not like to be thrown into that area for the default programs.

Thus, I am trying to find a method in the wizard screens to show what paths/files will be effected by SAFE (even if they don't really understand what will happen). It is how to fix such things that is tricky. I was thinking that a "fix" button could spawn a "walkthrough" for each item that is not found. Something like

Code:

"SAFE cannot find Firefox. Is it installed?"
[COLOR="Blue"]"yes"[/COLOR]
"Where is it installed at?"<spawn browse>
[COLOR="Blue"]"Here, in my e: drive, right where I put it, you silly program"[/COLOR]
"Thank you"

The apply and remove buttons exist because if the default paths don't exist, there must be a KISS method of addressing the issue. If the user has only IE and Firefox installed, they need only click those two objects on the left, then the right will show them if all is "green for go". They apply it, or remove it if desired. There can still be a master "remove all SAFE settings", but this give granularity, but more importantly, the method to verify and/or correct each component.

Like I said, it is a concept that I cooked up. I am glad to hear any input that can help.

Thanks. It is the first attempt, so maybe it will get better

Sul.

 

Haha,

What is the problability that an average user has installed firefox in E?

Let's get back to our design principles.



1. Safe Admin is a great security enhancement, because it creates
a) a clear border between High and Medium rights (facilitate only explicite installs by user, reducing staged malware installs)
b) a Lower rights world for all mainstream browsers and e-mail programs (which deals for 80% of the infections) not just for Chrome (best implementation) or Internet Explorer (protected mode), but also for Opera and Firefox.

2. The manual Safe Admin tweaks are even to difficult for the average Wilders Members, making it as irrelevant as AppLocker (also a great mechanism, but consumer market does not buy ultimate versions).

3. Your Safe-Admin freeware program should automate the process without having the knowledge to apply it. Benefit of Safe-Admin is that it is a set and forget security mechanism (you do not need to have knowledge to use, only knowledge is required to apply it, this usage threshold is taken away with Safe-admin).

4. Scope of Wizard implementation for the Noob and average PC Joe/Jane:
a) A Noob setup where everything is implemented standard
b) An average PC Joe/Jane setup who applies some structuring, meaning determining him/herself where the programs are installed with a maximum scope stretch of a Programs Partition and one or more Data Partitions or drives.

5. Wizard takes into account what the default settings are. Those are static but can be managed by ini-files (so when you decide for a dramatic hobby-change, people like Wat0114, Moonblood, Tlu, Lucy, Windchild, MrBrian etc are able to supply updated ini-profiles for the Noobs). Default settings support the 4a category Noobs.

6. Wizard reads the Registry values/system environment variables to deal with slightly non standard implementations (the 4b category Average Joe/Jane).

7. Wizard follows a procedure (as outlined in the left pane vertical of the wizards) and for each step it presents the defaults (top right pane) and when available the slightly different user specific settings (bottem right pane).

8. Dialogue complexity is controlled by providing the option to REVERT or CONFIRM the defaults or to REVERT or CHANGE or CONFIRM the user specific values.

9. Because Safe-Admin determines whether the values match (only CONFIRM or REVERT buttons = jpeg 18 ) or are different (only CONFIRM, CHANGE or REVERT buttons = jpeg 17), so there is only one set of buttons at the bottem of the screen (below two horizontal panes at the right): being CONFIRM, CHANGE and REVERT. where depening on the situation CHANGE is greyed out. REVERT button reverts the SAFE-ADMIN security for this program.

10. Pressing the CHANGE button leads you to the relevant tree of Custom rules setting. The Custum Rules (jpeg 20) has the following set of buttons
NEW = enters a new program group
ADD = add a new directory line
EDIT= changes the line you are currently standing on
DEL = deletes the line you are currently standing on.

Data entry for NEW (example)
Description = K-Meleon [name of the program]
Directories Binary - Program Dir - User Dir - Data Dir
The instruction explains that for a Mail program the User Dir can be used for the contacts, for a browser it is the location of the User Profile dir. The Data Dir is either the download directory or the directory where the mails are stored. A new program allways creates four entries (name plus 3 directories).

Data entry for ADD (example)
Description = Mail Archive (through keyboard entry)
Location = [through Browse button] D:\MAIL\Outlook Archives Kees

Data entry for EDIT
Description = current value (change through keyboard entry)
Location = current value (change through Browse)

Data entry for Delete
Pop-up Are you sure you want to delete line [Description, Location] from the list [YES/NO]

11. Geek options are in the EXPERT's section.
Maybe we miss out some of the user base potential by not making it super intelligent, but hey this category is screwed anyway. They have non-standard PC installations without having the knowledge. It is the dangereous category who think they know without undertstanding. SO when they pretend they have the knowledge of a an Expert, they can use the Expert's section. This greatly reduces complexity for the rest of us.

 

Sul,

One text comment: the explanations ad 4 Only allo signed drivers to elevate, it should be allow only signed executables to run elevated

ValidateAdminCodeSignatures
Only elevate executable files that are signed and validated

This policy setting enforces public key infrastructure (PKI) signature checks for any interactive applications that request elevation of privilege. Enterprise administrators can control which applications are allowed to run by adding certificates to the Trusted Publishers certificate store on local computers.

The options are:

• Enabled: Enforces the PKI certification path validation for a given executable file before it is permitted to run.

• Disabled: (Default) Does not enforce PKI certification path validation before a given executable file is permitted to run.

Explanation Certmag
Only elevate executables that are signed and validated policy setting. User Account Control (UAC) is a new security component in Windows Vista that helps mitigate the impact of malware. UAC limits administrator-level access to authorized processes by requiring all users to run applications and tasks with a standard user account. Windows Vista includes various UAC policy settings that can be used to control the behavior of UAC on client computers. The User Account Control: Only elevate executables that are signed and validated policy setting enforces PKI signature checks on any interactive application that requests elevation of privilege.

 

Ok, that was the one I put in last. I will change that on next layout. I wonder, how many executables that an average person uses will be denied then. Any idea?

Sul.

 

I believe I have found the direction to take this now. I am still working on the UI so that it becomes very friendly to those that need the help.

Let me pose a question for those that might use such a tool. When a program is going to manipulate system settings, such as the UAC settings in this case, the program needs to first record what the values were, in order to "restore" they system to the original state.

When the original values are logged, would you rather see them stored in the registry or an INI or .log file? I normally don't use the registry much. In fact, I have made a point to use it as little as possible. But I creating a tool now that is not for geeks, like I normally do. Is it acceptible to house data in the registry? Would you consider it a safer location than a INI file?

My thought is that if a tool like this is used, it must ensure everything can be removed and restored to the original state, else only advanced users can truly rely on it. I feel that an INI file is easy and fast, but also has a higher risk of being lost/deleted/etc. The registry, it imposes more gunk in the registry, albeit a very small amount comparatively. But short of the registry itself corrupting, seems to be the safer option.

What are your opinions?

Sul.

 

One thing, and let's see if I still remind it all.

Unlike Chromium (and based browsers) and IE, which run with Low IL, but not an explicit one, if we set, say, Firefox and Opera, to run with an explicit Low IL, then if we download an executable, for example, this executable will also have an explicit Low IL. It won't matter if it gets downloaded to a Downloads folder with an explicit Medium IL. It will fail to run.

So, in this case, there's no real difference between having the Downloads folder with Low IL or Medium IL, or even High IL. This executable needs to move away from that folder and, perhaps to a secondary folder with an explicit Medium IL... just for a smoother experience for most users?

Anyway, unlike what happens with Chromium or IE, that having a Medium IL Downloads folder with a NoExecuteUp would be sufficient.

Not that you wouldn't know this... You do... But, just giving the heads for others who may not know it.

Edit: By the way, when you finish SAFE-Admin, would be willing to provide the language file, so that it can translated?

 

I wasn't aware of this limitation. I will have to inspect this.

Has anyone noticed that if you have Chrome set to open last session, when it opens, all pages that were there from last time open at medium IL, and only new tabs after this have the low IL. This could be considered a flaw, as a page that was opened at low IL which had an exploit, then was opened automatically again later would run at medium IL. Seems goofy they would allow that to happen. EDIT: even stranger findings. If you open chrome with no pages from prior session, chrome parent (the handler) runs at medium IL. All new tabs created are at low IL. Then open 4 pages. Close chrome. Open chrome. Those 4 pages open at medium IL. Open new tabs, which start at low IL. Then close chrome. Reopen chrome, now 4 tabs again start at medium IL, and the new ones after them start at medium IL. A mystery as to why.

Regarding language, I have done that in the past, but the problem is that I have no idea how to fit other languages into the space provided. The size of the labels etc are static, so a shorter language could fit, but a longer one would not. I could make the help files and tooltips read from an .ini file if provided instead of the default. I did that in PGS I think.

Been playing with the virtualization and other UAC stuff. Tried once again to force an ACE to stop or allow an IL, but it cannot work. I read way too many tech articles today. Been playing in quiet mode UAC. I don't always like how virtualization kicks in I have discovered. I would rather a program gave an error it could not write than virtualize. I found conflicting evidence - an external manifest might or might not over-ride an internal one. Will have to find out about that. The registry shim doesn't seem to over-ride the internal one, which M$ said it would. Loads of fun

Sul.

 

By the way, forgot to mention it, and I'm not sure if has been mentioned before (Too much to read. ), but the browser's user profile data also needs to be set with Low IL.

Interesting... I did try it, and it happens. In my way of seeing it, it's a security bug? Otherwise, let's see: Chrome is suppose to run Low IL as a protection measure. This should be the default behavior always. It seems that, for whatever reason, it happens what you've mentioned. So, while people believe it runs Low IL, it is actually running Medium IL.

I guess it's a great thing I force it to run with an explicit Low IL.

It seems you've had an interesting day!

 

Interesting...

Without even doing what I did before (After you mentioned it), some tabs have Low IL and others Medium IL. (I'm not running with the profile with explicit Low IL. I have more than one chromium folder.

 

Sully, could you try to reproduce the following, having as base what I've mentioned before about Opera and Firefox with Low IL.

This is what I've come across, and is perhaps the best solution that fits our needs.

Steps:

Step 1.

Start Opera (Don't forget to have it with Low IL);
Save an executable file to the Desktop;
You shouldn't be able to run it.

Step 2.

Start Opera (Again, with Low IL)
Save an executable file to a folder with an explicit Medium IL;
You shouldn't be able to run it.

Step 3.

Start Opera (Again, with Low IL)
Save an executable file to a folder where both current user and HomeUsers group have no execution rights.
You shouldn't be able to run it;
Move the executable file to the Desktop;
You should be able to run it.

Let me know if you can reproduce this.


Edit: If anyone else willing to test it, go ahead.