The irrelevance of Applocker / relevance of SAFE admin tweaks

I am hoping that after I put all I think will be needed into those areas, it can be experimented with and then be trimmed down to what will be used instead of what might ever be used.

With some good layout and the right text, I wanted it to be logical. Step 1, you want to deny a Medium Integrity Level from reading a folder. Step 2, you choose the restriction (is it write or read or all or just execute). Step 3 you choose what user(s) this applies to. Step 4 you choose if this ACE will apply to the sibling files or any child objects or even grand-child objects.

I sincerely hope not to explain the technical aspects of hierarchy. It is not exactly complicated, but it is confusing. But I can see, not just for myself, that a convenient tool for the Integrity Levels and the ACL would let people who struggle with command line still do simple operations without having to know exactly what to do. That is the goal anyway.

Firefox will be a good example. I have a few others in mind as well. Without getting too technical, I think many users who understand file structures could begin to customize things a bit more than if they had to use icacls or similar method. Sure beats subinacl, thats for sure.

I will spend a little more time putting a logical sequence to those areas. See if it becomes less daunting once I have real text there rather than design outlines. I think all of you who are commenting are capable of using it, without confusion, if I do it right.

Sul.

 

Great Work Sul, I am not critising you. I have come to know you a little. For the advanced bit, you are structuring the solution in your head. Next comes the user interface and process guidance (what you are describing is on the level of WIZARD, guiding a user through complex process by deviding it into simple one object related steps). Those single steps have to be KISS (keep it simple & smart). What is confusing for some is that the simple (noob) tabs aallready have gone to one user interface refinement. The advanced are a raw mind dump.

Another example might be: CCleaner now requires elevation, what about a small explanation to run it without elevation request.

Problem is you need some feedback of experienced members, who have a little experimented with icacls to see how easy the advanced tabs are compared to Microsoft command line tools.

As illustrated by Newby who used this (problably no readup/write up/etc) to protect his data from stealing by low rights objects (being his browser and email as I understand it). It took him a week \. With your tooling such system hardening (advanced mode) would be available to a much larger audience. Others I strungling to run programs in LUA without elevation prompt. Once you know the drill, you have a tool which achieves simular things as SURUN does.

So for archuments sake why not split into the program into two sections (simple and advanced or even split it into two programs)

a) SAFE-ADMIN = contains the simple screens 1 - 4
Reason. This is a security enhancement of people running ADMIN in default mode

b) FLEX-USER = contains the advanced screens
Reason: targeted audiwnce are either
1. Admins running in quiet mode (auto elevate) and wanting to tweak their system to their needs
2. Power users running LUA, wanting a tool to manage programs needing ADMIN rights

Just my 2 cents

Regards Kees
(still fighting jetlag)

 

Absolutely great! I finally figured out how to completely remove the Integrity Level from an object. Not just relabel to the default Medium which would probably be used, but remove it entirely.

I will go through the advanced menus today and refine them for a wizard type of feel, where you advance each step with a feeling of what and why. One still needs to know what they wish to do, but the UI might possibly make some sense.

I will also visit the tab that turns the Internet Zones execution control on/off. I think the logic in that is incorrect.

Now though I have found all the means to do everything internal, so I don't need anything but what is already installed on Vista and 7. Don't know about XP for some it, but I think it should all work because I am not going to use icacls on the integrity level stuff. I will likely try to use cacls on machines that run XP, not sure yet.

Sul.

 

That's great news, Sully.

Something came to mind, while working with ILs in my virtual machines. I set a folder with High IL. This means that any object with a lower IL, like Medium and Low, won't be able to write to this folder, if I only set the IL to High, that is, because, any object is automatically given a write deny (NW).

Taking in it a bit further, setting this folder to NR (NoReadUp), will prevent lower ILs from reading this folder. This is great, in case we got sensitive information inside this folder.
So, now the folder has High IL, NW and NR. One could even go further and deny execution.

That's great!

But, say you want to create a document or place some file/folder within that very protected folder, you'll need to be running from a High IL.
Now, since I believe most will be using either a LUA or Admin with UAC, that means that, by definition, every object will run with a Medium IL.

One way to be able to read/write/execute this protected folder would - I see why not, really! - run an elevated cmd prompt and then run, say the text editor you make use of, and then save the file in the protected folder, which otherwise you wouldn't be able to save there, because this text editor would be running with a Medium IL.

By the way, not really needed to run cmd prompt, unless I desire to create folders and copy/move files/folder from and to this protected folder. So, executing everything from an elevated command prompt saves me time, I guess.

Unlike ACLs, that - If I still well remember!! - allows an Administrator to access a folder without read permissions, by entering credentials, with ILs is not the case! You truly need to have access through a High IL object.

That's neat.

Anyway, what I was wondering was:

Would it be possible to have a section in Safe - Admin where one could let the program know which folders we consider to be sensitive and automatically set the folder with High IL, NR,NW and perhaps NX?

For what I still remember from previous threads, it is not being developed with this minor thing in mind, or is it? (Sorry if it is... But, I truly don't remember, and there goes 8 pages by now... I haven't rechecked... Sorry.)

What do you think?

 

Yes, that is the purpose of the advanced tabs I have been working with. Kees put it rather well I thought when he described them as "a raw mind dump". That is exactly what it is - first ideas that come to mind.

Here is a modified version in an attempt to streamline things.
http://mrwoojoo.com/safe_admin/IL_1.jpg

I believe that design might be more user friendly, but will wait to hear what others think before gonig any further with it.

Regarding the more technical aspect, I may as well give a description now while it is really flowing in the brain juices. (gives me someplace to reference later too ) .. forgive me if anyone already knows this .. and as always I don't pretend to know everything, there may be errors

In the M$ world, everything is an object or container. Well, there are services and registry keys, but we will ignore those for now.

Objects are files. Containers are directories. Every object or container should have an Access Control List or ACL. Within this list are the rights for users and groups to be allowed or denied different things, such as read or write or modify.

The ACL is really comprised of two different lists: the DACL and SACL. The DACL stands for Discretionary Access Control List and the SACL stands for System Access Control List.

Since an ACL is a list it can hold more than one item. The items that it holds are called Access Control Entries or ACE. Both the DACL and the SACL each can have one or more ACEs. Sometimes you see DACE or PACE for the DACL ACEs and SACE for the SACL ACEs. It can get confusing for sure.

Each ACE in the Access Control List is unique. One ACE might be to allow the Admin group full access, and another ACE might be to allow users to read and execute, and yet another might be to deny users modify or delete rights.

Since there can be mulitple ACEs in an Access Control List for an object or container, there must be some form or ranking to determine which permission comes first. As it so happens, this is called the hierarchy. But before we can understand how the hierarchy works, we must understand a few more things.

Inheritance. Without going into a lot of detail (because inheritance is complicated) it is enough to state that a top level directory like c:\Windows has what are known as 'children'. Child files and child directories. Within these also exist children. So c:\Windows is the Parent, c:\Windows\System32 is the child, c:\Windows\System32\Drivers is the grand-child, c:\Windows\System32\Drivers\etc is the great-grand-child, etc etc.

Each Parent can give its child(ren) an inheritance. The inheritance is of course not a Ferrari but only the rights it was assigned in life. Or, the parent can choose to not give its children inheritance. It goes on and on, whether the child in turn gives those rights to its children (the original parents grand-children) or not. Some children can even be rude and deny the inheritance that is trying to be offered them.

If an object or container has inherited an ACE in its Access Control List, this cannot normally be tampered with. It is called an Inherited ACE (each ACE in the list is examined separately to see if it is inherited or not). If you or a program were to add an ACE to the list it would be called an Explicit ACE. Explicit ACEs can be tampered with.

The hierarchy gives the Explicit ACE the first shot at dominion over the rest. And further, it gives Explicit ACEs that DENY dominion over Explicit ACEs that ALLOW. So the order is from strongest to weakest (or who gets to allow or deny)
Explicit Deny : Explicit Allow : Inherited Deny : Inherited Allow

There is also a hierarchy among the DACL and SACL lists. The SACL lists are examined before the DACL lists. This is why Integrity Levels work the way they do (in part anyway).

Most of the objects and containers in windows do not have an SACL at all. A few top level directories do and a few other areas. But for the most part if you start a program, the integrity level it gets will be inherited from whatever started it. In the case of LUA, it is usually Medium because LUA itself starts as Medium, and everything cascades down from there. Core parts of the OS will use a High Integrity Level and many services use an even higher one called System.

Since the SACL is processed first, you can put in an Explicit ACE into it, and it will have dominion over any inherited ones (it gets strange is all I can say). When you use icacls or chml to change the Integrity Level of something, what you are doing is creating an Explicit ACE in the SACL list. This is why an Administrator can own a directory, but if he starts a process at Medium Integrity, that process may not have access to a folder he owns. The SACL was examined first, and it has dominion over the DACL which has the information that would normally allow him access. It all depends on the settings too, this is simplified you know

Each Integrity Level has what we humans know as levels, such as Low, Medium and High. But those are only for our benefit. The computer sees them as what is known as SIDs or Security Identifiers. An example of an SID would be S-1-5-32-544. This SID is for the group Administrators.

Humans interpret it by using the RID or Relative Identifier. It puts the SIDs (which who can remember?) into forms such as SECURITY_BUILTIN_DOMAIN_RID or commonly seen as Administrators.

Each ACE, whether in the DACL or SACL, defines what it will do and to whom it will apply. When the SACL contains an ACE to set the Integrity Level, it uses the Low, Medium or High SID. When the DACL contains an ACE to allow or deny something, it uses a groups SID or an individual users SID.

If you wanted to deny any Medium level process from reading a file or folder, you can go about it in two ways.

The usual method would be to add an Explicit ACE in the SACL - that is you modify the Integrity Level. Because the SACL is examined first and applied first, whatever it says happens. If you set an Integrity Level of High and don't allow lower Integrity Levels permission to read, then no matter who the user is, be it admin or LUA, if a process they start is at Medium or Low level, that process will have no rights to read the higher level object.

Since the Integrity Level of Medium has an SID, you can also add an Explicit ACE in the DACL. You create a deny ACE for the group SECURITY_MANDATORY_MEDIUM_RID. Now the SACL is examined first, but has no ACE, then the DACL is examined. The Explicit ACE that you created to deny Medium Integrity Level access is process with the most authority, because of the hierarchy. The result is the same, a process at Medium or lower Integrity Level will be denied whatever you chose as your restrictions - read or write or modify - whatever you chose.

I think I have laid enough out. It is a complicated mess of things, but one that is worth knowing if you are a nerd like myself.

Sul.

 

Great to know it is part of Safe - Admin. I, somehow, missed that IL tab. Bummer.

I foresee Safe - Admin to be a tool of great value, indeed!

 

Why can't internet research answers be as simple as you just put them, Sully? Lol, I can't yet say I still understand what you said word for word, but slowly I'm coming around. At least I get the parent/child process idea now, lord, it's no wonder I couldn't use HIPS. Now if HIPS software vendors would, just for one time in their lives, make their prompts that simple. Anyway, on topic, your newest screenshot looks good. It seems to be well laid out and, provided users either have read your explanation you gave, or, use the help file (which is hopefully just as understandable), then users shouldn't have too much issue figuring out what is what, and what they feel comfortable touching and don't.

 

It seems there is another issue to be dealt with.

I was playing with the Integrity Level, how it works on files and folders, how the different inheritance options effect things. Getting the IL off of a file or folder I now know how to do. But, once you introduce inheritance, it gets complicated. Again.

Suppose you want to make programX.exe have a Medium IL. You use icacls or chml to do this. Now programX.exe has an explicit Integrity Level of Medium. A Low level process that starts programX.exe cannot raise it to Medium, it is forbidden, so programX.exe will now start at Low IL.

A higher level process, say one that is using High or System IL, when it starts programX.exe, is allowed to start things at a lower level, so programX.exe will start at the Medium IL you told it to.

Wherever you move programX.exe to, this Medium IL goes with it. It has no real inheritance as it is only a single object.

Now suppose you have a directory that you want to restrict from being touched by a Low IL process, such as IE in protected mode. Since the default for almost everything is NoWriteUp and Medium IL, IE can read and execute to any Medium area, just not write. But suppose you have a directory that you have your passwords in. (yes, not clever, but an easy example) You would want to protect this directory from even being read from Low IL processes.

So, you decide to set its Integrity Level to High so that only High level processes can read it. You presume that only an elevated program by an admin could be able to touch it then, which is probably true. You use icacls or chml to do this, and you don't apply any inheritance flags (the OI and CI stuff).

Now when a Low IL process attempts to read in this directory, it cannot. But, because you used no inheritance, any subdirectories (I think) are open to being read. You must state when you set that High IL that you want it to be passed onto subfolders and/or files as well. This way, everything inside the directory, all the way down to the last directory, can also have this High IL so that nothing inside can be read.

You might have a directory that holds programs you don't want executed, so you use chml to set the NoExecuteUp flag on that directory. The same thing applies, if you don't state you want that rule to apply to the directory AND any files in the directory, it won't apply.

Using cacls seems to apply a setting on a directory to subdirectories, even though documentation states otherwise.

Anyway, if you want the directory to stop execution for all levels but High IL, you have to tell it to inherit that setting to all files and/or subfolders. It does work if you do this, quite well. But, it does it too well. Once you set that option in place, it stays on every object, even if you remove that option from the directory.

Once you tell a directory to give its permissions to any/all files and folders within it, those objects do get the Integrity Level. But you cannot do the reverse. You must remove the Integrity Level of each and every object individually.

I looked into this, and the only program made that can do this that I find is SetACL. But I looked that the source code, and all it does is to recurse the objects under it. I can do that too, but it might be a slow process if there is a lot of sub-items to do it to.

The fact of the matter is that when you start messing with Integrity Levels, in order to make them work dynamically, you might need inheritance, and that can be troublesome (relatively) to undo.

I think it might be better to apply an Explicit ACE in the DACL instead of the IL in the SACL. Explicit ACEs in the DACL can be removed easily. I think the flag to apply to all sub-items exists already. You can also reset all items to use whatever permissions they should have inherited.

This means that, I think, it might be better to add an entry to DENY read or write or execute to a directory/file for the group Medium Integrity Level (or low, high, etc). The result is the same, that a process running at that level will be denied. Applying it to an entire directory is simpler and removable (I think).

You would reserve the Integrity Level setting for only executables or single objects you wanted to force to run at a certain level (probably Low IL).

More to come, I am sure of it.

Sul.

EDIT: I have scads of batch files and scripts, directories and executables all over the place now while doing this. It reminds me of why I hate using LUA. This IS what I do and why I always say LUA is a PITA for me.

 

I shall envision that the first tabs anyone could use and understand. Well, you do have to know something, but relatively little.

The tab you refer to would definitely be an advanced tab. I would assume that for a person to want to use that tab, they would already know they want to stop something from happening somewhere, which is most of the battle. Understanding inheritance could come at a slower pace, as it might be more technical, but I feel less of a battle as first understand that you need a restriction, why you need it and where you want to apply it.

I have a feeling that the IL tab will be much more basic because of my post above. If it all holds true, the ACL tab will be the one to use for more purposes.

Sul.

 

More strangeness. I had the Explicit ACE in the DACL set to deny the Medium Mandatory SID and it was working. Now I can't get it to work. I don't know what I did, as I have tried hundreds of different sequences. I got it to work, then moved on assuming it would work all the time.

I went to playing with the inheritance of the deny ace, and I cannot duplicate what I had done earlier. I hope this was not a fluke event that is only reproduced under irregular settings. I have been hammering on some test directories and files with a lot of scripts and tools I made, so there is no telling really how I achieved it.

All I know is I will be very disappointed if this does not turn into a method to use, because it means relying on Integrity Levels for everything, and while it works, it is not an ideal solution IMHO for inheritance issues.

To be continued....

Sul.

 

Great work Sul,

Safe-Admin will be great. What I really want to compliment you with the fact that you are able to remove the IL. Teh basics are described by M$, but they are not consistent and use different means of achieveing things.

I have not found a way to use default mechanisms to remove the IL completely. This allways was a bottleneck of easily accomplishing things. Even the author of the VISTA's Admin guide, made its own tool because he could not get it working.

In other words a knowledgeable amature has achieved something a highly recognised professional consultant was not able to (for all clearity not me but the author of Vista Admin Guide).

I am amazed with your progress, never had thought you would bring it this far.

Edit: Bummer I did not see the other posts. I am on a thin line so when typing this message I did not see you could reproduce your deny trick.

 

MS will have to get Sul on to their payroll as a Technical Fellow. He'll become the next Mark Russinovich

 

Sul,

I now understand that IL inheritance have to be removed of every single file or subdirectory. I once ran into a simular problem and used the current user in stead of the home users group to revoke the rights.

Also when you run into trouble of repeating sequences, please try with a new containers and objects. Using an existing test set, can mess up things.

Regards Kees

 

Another tip:

When you look at the usage there are a few things

a) Providing a process high/medium/low rights (for experts to eliminate UAC elevation prompts, sort of how SURUN allows processes to run elevated, or set FF to run with low rights)
(changing IL)

b) Restricting execution rights on a specific directory for home-users group
(adding a deny ACE)

c) Putting data leakage restrictions on directories
F.i. newby does not want to have low-rights processes read access to his data directories (or like your example a directory where you store your passwords in). setting all but download and upload directories to no read up/execute up for low rights processes.

d) manually setting (containers) to have read/write/execute rights so processes of a (e.g. FF) can use their working directories.

I would suggest that decreasing rights you try creating a special restricted SID. This might be easier to apply and REMOVE

Cheers Kees

 

I have thought about this. I will have to put my copy of Vista back on to play with at some point.
In win7 though, (I can't remember in xp/vista) it probably won't be needed. Lets see if I explain this correctly.

If you read my post above on inheritance, you can follow along. A parent directory, lets say c: or desktop, is going to give new folders and files that are made within it an inheritance. It is going to, no matter what you do. If it doesn't, you won't be able to use it. At the least it will allow the "system" full access.

Anyway, typically the new folder/file will have a few rights besides just system. If you run icacls.exe on that file/folder, you will see all of these. If you see an (I) it means that permission is inherited. Ones that are not inherited will say (Allow) or (Deny). These are the Explicit ACEs. They take precedence over the inherited ones. They are also the ones that can be modified or removed (if you have the rights to do so).

In win7, when you open the security properties, you can edit the permissions. Any permission that had an (I) in icacls.exe, you will note that they are always greyed out so you cannot disable or modify them. This is good for us!

So what happens then? If you want to add a DENY permission to a file/folder, you do so with icacls.exe or other tool. This is the only Explicit right and the only one you can tamper with. Even if an inherited permission has the same SID as the Explicit permission you created, you cannot remove it, ONLY the ones you created.

So we might assume that (in win7) if you have not futzed with your permissions in any way (and most probably won't) that any changes you make will be the only ones that can be removed, meaning it becomes easy to NOT make an error.

Maybe someone else can examine different service packs of XP and Vista to see if this is true for you.

This was by far the most complicated piece. In the end, it came down to the inbuilt mechanisms doing something that sort of made sense, but one that I would never have tried without a small blurb I found somewhere that made me realize what it might do.

Making your own tool, I would imagine that was also because of having to recurse all the files. Using some APIs might expose a method. If I could get my hands on a security template for win7, I might be able to figure it out. But, it is no longer the same as it was in XP.

I am half thinking of tearing into the win7 WIM (the install image on the DVD) and figuring out where the default template is. There must be one IMO.

The thing I don't understand is that there is a mechanism to use with the DACL and SACL to make the removal of the IL happen to the parent and all child objects. But I believe it has somethng to do with the fact that M$ shoved this "Mandatory Label" into the SACL because it was the only place to put it, and it does not behave in standard ACL fashion.

If I can figure out how I got the deny ACE to work on those IL SIDs, I won't even bother with it most likely. If that was just a fluke, then I will be forced to search a little more for the solution rather than creating a recursive function. Recursive functions like that can be notoriously slow in the wrong situations.

Sul.

 

Yes, but it is real world scenario. You have directory, you change/apply/configure, change your mind, reconfigure etc.

In testing that is what I was after, will it error. What causes the error. Is it repeatable. It just so happens rather than finding an error, I found an attribute. Alas, as of last night I made a dozen or so scripts to try and get it to work again, on new directories, and could not.

It reminds me of the time I was messing around in XP with some of the autorun reg hacks, and somehow got my machine to ask me to allow an autorun or something like that. I never could get it to do it again. Total bummer.

In thinking further on this, I am not sure it could be done, at least not easily or without special attention. Think about it..

A logon session exists for you the user who is logged in. If you are member of admin with UAC your token has two descriptors - one for the user as admin - one for the user as a user. The SID of the user who is logged in is known. I am unlcear but believe that the SID will be the same in each token, just the rights will be different.

Anyway, if one were to create an SID that was special, it must reference a user account. But, when you launch a process by double clicking it or whatever, you would have to start it AS that user whose SID is special. Not the best approach I think.

I will code a tool up tonight that reads the SID of a process, or its security descriptor, and see if a process started with UAC at admin is the same SID as the one that does not need UAC at all. This will tell whether the tokens use the same SID or not.

If the SID of the SUA is a known value and static, then it might be possible to just deny a right to a directory based on the token of the SUA. So in effect it does the same thing, only an admin SID would be able to access the directory with the restriction.

I think right now that whatever I did to get the Deny ACE to apply to the Medium IL will not be easily repeatable. I of course will attempt it, but after looking at Process Explorer more, I don't think the IL can be used in that fashion normally. The SID is known for Medium IL, but I don't think it is passed in the same way that the SID is of a normal group.

I really have no idea, but I will.....

Sul.

 

I believe it to be official now, the SID of a Mandatory Label (a specific Integrity Level) can be used in a DENY entry in the DACL, but has no effect.

I have confirmed that what I did when it worked was adding more than just that DENY ACE. The directory being tested had other factors at play that I did not see. It is most unfortunate.

But I did learn a little more about why it won't work.

The SACL, as stated, has priority over the DACL. Starting in Vista, MIC (Mandatory Integrity Control) or WIL (Windows Integrity Levels) was implemented. The technology says that everything pretty much, from a process to a security token, must have an Integrity Level. If it is not found, one is provided for it. This, the default IL, is set to Medium level with the flag NoWriteUp.

The SACL is normally used for auditing purposes. If user/group XYZ attempts to (open/read/delete) this file/folder, then audit (alarm/log/etc) the event. In Vista the new "Mandatory Label" type of ACE was included for SACLs.

When a process/etc is initiated, a security check is performed. First the SACL is checked. Is there an Explicit Mandatory Label? What level is it (High/Med/Low)? If one is not present, give it a Medium level.

What is the Mandatory Label of the security token that started this? Is the security tokens Mandatory Label lower or higher than the process trying to start? One should be present else it will be given one (it will be present though).

If the tokens label is higher than the process being requested, or equal to, we can allow it.

If the tokens label is lower than the process being requested, then we deny it.

All of this happens before the DACL - which is the Access Control List being used for files and folders - so no matter what rights (allow or deny) exist in the DACL, denial might happen before it is even checked.

After the Mandatory Labels are compared, if the process is allowed to continue (ie. a program is starting or a file being opened) then the DACL is examined. Each permission in the DACL is linked to the user account by that SID or to a group account by SID. If the user starting the process is a member of a group that is denied, or thier user SID itself is denied, then whatever right that has been denied takes place.

If there is no denial, then for the process to continue, there must be an allow. The allow permission might be for the user, or the group the user belongs to, or just an allow permission for Everyone. Without an allow permission, the process is denied.

The Mandatory Label/Integrity Level is a first line of defense that builds upon the DACL. It disallows even reading of a higher levels memory space by a lower level process.

The security token that the logged in user has contains the SID of which mandatory label it contains. For a moment examine the difference between running as admin with UAC on and UAC off.

With UAC on, the LUA option is enabled. Here, the security token of the user contains the Medium Integrity Level. It is declared and assigned to the token. But, the actual SID that references who the user is points to the user account (such as my account, Sul). While the Medium IL is referenced by the SID, it is only because everything, including a security token, must have a Mandatory Label.

With UAC off, the LUA option is disabled. Now the security token of the user contains the High Integrity Level. It still contains the same users SID (for my Sul account). It is no different.

When either of these two situations above, UAC on or UAC off, starts a program, the SID that is being passed along with it is the SID for your account (or the SID that references my Sul account). The security token of the new process created is the same as the one that started it, unless an Explicit Integrity Level has been applied to whatever we started. But the important point is, the SID that the DACL will use the Allow or Deny permissions is not the Integrity Level SID, even though it exists. It is your SID, or my SID -- whatever the user logged in has.

And more than this, when you login, you are given a unique and temporary SID. It will change on every login.

I also examined how using DropMyRights might effect things. I already knew that when you change your security token to that of a User from Admin that the SID is the same. In laymans terms, when you start a program as yourself, but you demote yourself, you are still yourself at core. You still own the same things, have the same SID, same everything. You are just seen with less rights than normal.

Integrity Levels work in much the same way it appears. I should have double checked my findings before letting the cart run away with the horse.

I cannot see how one could ever use in-built mehanisms such as DACL to create a special user class without using some form of RunAs. All the elevation that takes place uses the same user, only with reduced or elevated rights. Without a different SID, I don't think it will work. And the only way to get an alternate SID is to execute something AS that alternate user.

Those using traditional account who is a member of the Users group and not of Admins will see things differently. They will truly see an SID that is different when they elevate because the Admin account they use to elevate with is different from thier standard User one.

I have not played yet to see if UAC (automatic elevation techniques in general) work in a true LUA instead of SUA. Maybe someone can post what they find happens.

None of that matters in the case of SAFE Admin though. The end result of hours of experimenting is that we have Integrity Levels at our disposal, and they are a fairly robust feature. It will be up to me to find a method to manage them easily. I will say this, a Mandatory Label does not behave the same way as the traditional SACL entry would. It is a completely new structure shoved into an old house. It works, but is pretty undocumented in many respects this technical in nature. I am suprised I even figured out how to remove it without resorting to some APIs, which would do it.

That is enough for now. I will shift gears and take a modified direction.

Sul.

 

Wow,

Policy management is kind of tricky because M$ used an old and a new mechansm. Also one depends on old mechanismes and the newer one is more developed with object orientation (and inheritance) in mind.

The hierarchy of things (look f.i. at the lazy admin website) is allways an issue when professional system/network administrators seek help(most of them are microsoft certified engineers and still have trouble with it).

When you are done, some tutorial would be a big help for professional IT-guys. Few have dived so deep as you are doing at the moment.

Curious Kees from HUE, Vietnam

 

Indeed there are good reasons why Microsoft created integrity levels .

I don't think of integrity levels as being "above" DACL. Rather, I think of them as being two "gatekeepers" that must be passed before access can be granted - i.e. the end result is the same, regardless of which is checked first.

 

I can see why you view it like that. They are two different methods that work together.

I do see Integrity Levels as being "above" DACL though because technically the Integrity Level is a core component of every process,token, job, thead, etc. And further, the system will give an Integrity Level to anything that does not have one. Not only does all of this happen before the DACL is examined, but happens regardless of what the DACL contains, and has the power to effect the DACL per user.

Even with that though, the DACL still has the actual say in what rights are applied to the file structure, so it is not "less important". It is only "less in authority" than it was prior to Integrity Levels.

I have this strange feeling that DACL can still play a role other than the way it is currently being employed. I have dozens of ideas running around upstairs that I can't quite put into action yet because I still don't know enough to do so. I found some new infos regarding ACEs, one that I want to play with IF I can find enough example documentation to make it clear. That is always the trick with this stuff - msdn lays it all out, but leave it to you to understand the entire structure of the OS, rather than assuming you know a lot about a few aspects and only a little about a lot. I think that is where most geeks are at. We focus on what we need, and in some areas gain a lot of infos, but I for one cannot learn the whole OS in detail. M$ assumes so though, or they assume you want to continue following the myriad of links all over msdn to find out. That is slow going usually.

Anyway, I found a few more resources that cover IL. I am curious to see more of the "meat" and less of the "potato".

Sul.

 

First and foremost, I'm sorry to interrupt the flow of discussion between the 2 of you (Kees and Sully)

I'm running under a LUA+SRP setup with a few others currently on Win7 but I need to know these 2 things:

1. If I were to use SAFE-Admin to change the settings in the default admin account with standard rights (thereby providing some benefits of LUA in an admin account), would it affect my current LUA settings?

2. Would it be fine to use SAFE-Admin with default-deny SRP? I assume yes but I'd better seek the clarification from the 2 of you...

And yeah - Is it possible for me to download the alpha version for now since I'm particularly interested in trying out the settings in Tabs 1-4 (the simple ones) without having to resort to applying them manually myself.....

 

It is not possible to download the alpha yet because I have not produced it yet. When it needs to be tested, I will announce it here for those intrepid souls who wish to test it.

Regarding the other questions, SAFE-Admin is only a user interface to Kees methods. Some of those methods effect an admin/SUA with UAC. Some would effect every user. How it will effect you will depend, and not one that I could predict entirely. If you are LUA then switch to SUA/UAC, there will be differences. Most likely the differences will relate to when using LUA the admin owned a lot, but with SUA you are the admin and owner. Things of that nature. Also the info in the %useprofile% of the LUA will not be in the %userprofile% SUA, so shortcuts may need to be created or files copied. That assumes you stop using a "user" account and start using "admin" account with UAC turned on.

Sul.

 

Add-1
When you would not use the 1806 trick (tab 4), it would not affect it. Onlythat LUA has a deny execute from download directory and mail directories. It would be a great hardening of your admin account. When you use Chrome (from Google Pack) or Iron, than you can also use the 1806 (4th tab) trick. Because Chrome/Iron allows download and removing the execution block with right click under LUA.

Add-2
With the tabs 1-4 you create an extra default deny, a second layer with SRP. I have set this up on my wife's PC (so you got the SRP default deny, the ACL default deny of download and mail directories plus a default deny on ACL of every executable downloaded with mail or browser. When you use the windows zip, it even skips executables while extracting.

 

I have been wondering why I had the DACL deny to work at one point. I bothers me.

I spent the last few hours pouring over SIDs at msdn. Something nags at me to investigate deeper. I have most of a tool made that will find the IL of a process as well as the SID. However, there are other options that I have never cared about.. until now.

I tend to chase shadows, wondering if something can be done.. differently. I am going to chase this shadow for a little bit, and see if there isn't something to it. I will not chase it for long though. After this I will shift focus back to the UI of the tool. I feel much of the hard work is past and the focus can be made on the UI.

When the UI seems well enough, I will start attaching the functions.

There is more to the SID structure, the access token and how the DACL controls the access to an object than just "is it allowed or not". There are flags in there that I don't know but am curious to see how they are set, and further, if you can change them and how to do it. You know, run of the mill techy stuff

Sul.

 

The option to add an Alternate Data Stream to files downloaded from the Internet Zone, located here

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]
with the dword key of 1806 have the following values.

0 = off (the ADS is still created though on NTFS partitions)
1 = you will be prompted to run this and informed it could not be verified. A checkbox allows you to remember this answer (meaning don't ask again). This is encrypted/obfsucated in the registry, with no way I see to automate such an event without the key/algorithm.
3 = you will be notified that you cannot execute this file
5 = you cannot execute the file, and will not see a notification


EDIT: Here are some screens of the latest idea for the ACL advanced tab and the Drive-by protection tab (using the Alternate Data Streams and the Internet.Zones ZoneID method.

http://mrwoojoo.com/safe_admin/ACL_1.jpg
http://mrwoojoo.com/safe_admin/drive-by-1.jpg

Here is a question about how to 'unblock' a file that was downloaded from the internet when using the 1806 reg setting.
The ZoneId value has different meaning.
3 means the file came from the "internet" and the Zone Restriction can apply.
1 means the file came from the "intranet" (the LAN) and Zone Restriction is not normally set for that.

So would it be better to modify the ZoneId value to 1 or just delete the value(s) completely?

Sul.

EDIT: I have a better idea now that will make this much easier that all those check boxes, radio buttons etc. Save room and make things simple.. hopefully.