The irrelevance of Applocker / relevance of SAFE admin tweaks

Not sure that I understand what you mean, or maybe I haven't seen it like that before.

On a default win7 install, using any browser but IE, when I download items to my 'downloads' directory, even with UAC on, I am never asked to allow it to run unless it needs admin rights. Then UAC comes on and does its thing.

If I am an admin and turn UAC off, I can then run whatever I download. It is not until (for me) the 1806 setting is changed do I either get a deny of downloading or a deny of executing without an unblock. I have not seen the prompt that allows an unblock, only a prompt that says I need to unblock it before going further.

Can you explain what it is you see and what the settings are that you have that achieve this?

Sul.

 

A little OT, but I kinda get the feeling that here on Wilders there are the LUA/default-deny types and there are the ones that like to use 3rd party software such as antivirus/behavior blockers/HIPS programs. Each likes to tweak the system by either always messing with the settings in Applocker or the registry while the other group likes to try out different software programs, usually depending on the latest av-c report, or something similar.

It's similar behavior in a way for both groups- always changing, trying something different, tweaking things. And each kinda stand-offish from the others' preferences. There are differences in techniques but continuing similarities remain- always trying something new, usually just for the hell of it. It seems there are more similarities than differences. But as in most rivalries, if that's the right word, the differences are pointed out more often.

 

A decent summary I believe. However, the real key IMHO is the choise to remain as an admin. This is what drives me anyway. I concede that Tlu, Lucy and Windchild have a method that is very tried and true. It doesn't pose much in the way of difficulty and is very secure for the most part. However, it also is constrictive to how I use my machine, so I look for ways that are hopefully built into the OS to reduce the effect that being an admin will have for me.

But you are correct, a lot of us enjoy the learning and trying new things aspect of it. Rivalry is a word I would have mixed feelings about because I am not really in a competition with that camp, more like I am trying to come up with some sort of compromise that brings me closer to it without the same level of restrictions. I don't know of another word that would fit properly really. Rivalry is a pretty close fit.

Sul.

 

Yeah maybe not rivals. And there are probably more ways to divide up the schools of thought- there are the sandbox school, snapshot school, default-deny school, av school. And several times these overlap into each other. So maybe the admin/non-admin is the litmus test since most people subscribe to either one or the other.

 

I'm running as an Admin User in Win 7 Pro. To the best of my knowledge, I haven't changed anything concerning downloads other than notify AV in Group Policy. I downloaded BkavDetectShortcutFileVirus


As you can see from the picture, it's already been run since it has BkavDetectShortcutFileVirus.log
Here is the properties dialog before and after running the file


Anytime I want to run the file, I get this


Clicking Run allows it to run with the Block still applied to the file. I guess the answer to my question lies in your repy above where you state that "using any browser but IE". I was under the impression this tweak was for IE also which didn't make sense.

Forgot to mention, the only way I do not get the Run dialog warning is if a downloaded file is pre prompted with the warning bar at the top of the browser. If the warning bar pops up and I select to download the file, the file has the block on it but will run after providing credentials through UAC and the Run dialog warning does not come up. After the file is run, the block is still in the properties of the file which also doesn't make sense but I guess accepting to download through the warning bar has carries more power than if not getting the warning bar. Don't know about that one.

 

Greg S,

As I have told earlier the 1806 trick is not a hack, just a change. In stead of the last warning prompt (when you run it), it will block execution with a warning display simular to access control list deny.

With value 3 it blocks and 1 (which is the default) it warns

 

By now you who are watching this thread and this method of Kees are aware that I am going to create some sort of "front end" for it, so that it will be "easier" to implement. I have started a journey now that I was no prepared for, but none-the-less offers some nice forays into some inner sanctums lol.

A little light reading then:
http://msdn.microsoft.com/en-us/library/bb250462(VS.85).aspx
http://www.icranium.com/blog/?p=1036

And some tidbits:

It is interesting that the SACL houses the ML and is checked before the DACL, thus the IL is actually, in a hierarchial scale, above DACL. This MIC or WIL as it is referred to, has more to it than meets they eye, especially if you take into account UIPI ( User Interface Privilege Isolation ). The security boundry (although M$ doesn't appear to call it that) of the 'desktop' still seems somewhat confusing, as in one instance it is segregate, in another not so much, apparently by design so one can use such things as OSK (on screen keyboard) across all desktops. Regardless, WIL/MIC is quite fascinating.

This gives some more specific meaning to UAC and how the tokens are used. I always find things easier to understand when they are written in geek

I thought this was a pretty good writeup on DEP and ASLR.

I have much of what Kees has designed working now. I found out recently just how easy it is to manipulate the ADS (alternate data stream) of a file. Really easy. I also found out that you can pack an executable in there if you so desire, or program settings. Could be used in a lot of creative ways, or a lot of malicious ways. Still, as the objective is to simply stop or prompt for execution in this case, it seems easy enough to manage and can serve a purpose for the user who is expecting it.

Currently I am knee deep into a much more complex beast, the ACE/ACL stuff, especially in how the Integrity Level comes into play in different ways. Once that is tamed, most of this research should be done and I can start some betas to see what happens.

All in all, even though Kees probably did not plan it, it has been a MOST rewarding journey. Of course, many of you can only roll your eyes and think "better you than me", lol, and perhaps you would be right sometimes

Sul.

 

I will present a few questions for those of you are into this sort of thing, along with a helping of a peculiar dialect of geek

I am investigating the mechanisms of Integrity Levels, how to manipulate them. Chml is a good tool, but I hate having to have dependencies, so I try to do it natively if possible. Anyway, this has led me back around to one of the most confusing aspects (inheritance and propagation) of one of them most confusing syntaxes (SDDL). Lets see if we can develop any strategy from the methods that are available to us, once we understand them.

For a primer, I will explain quickly what a DACL, SACL and ACE are, as they make up the SDDL. The SDDL itself is a structure used in an .inf file to set Access Control on many different objects, such as registry keys, files and services.

An ACL is an Access Control List - pretty simple.
An ACE is an Access Control Entry, which resided in an ACL. There can be more than one ACE in an ACL.
There are two sorts of ACLs.
The DACL (Discretionary Access Control List) and the SACL (System Access Control List).
The DACL holds things like ownership and permissions for an object (a file) or a container (a directory or folder).
The SACL was not used much in the old days that I ever found, only for auditing and things of that nature.
(bear with me, the Integrity Levels use the SACL so it will tie together)

The cryptic language of SDDL is not too hard to understand once you find some laymans terms for it instead of what M$ likes to give out. A simple one might look like this
O:BAD:AI(A;OICI;FA;;;BA)(A;OICI;GRGX;;;BU)

The O is owner, separated by : and the BA is Built-in Administrators.
The D is for DACL (S: would be used for SACL), separated by : and the AI means to Automatically Inherit or propagate this DACL to child objects or containers.

The remaining are the ACEs that will be applied to this directory or file.
A stands for allow.
OI stands for Object Inherit
CI stands for Container Inherit
FA stands for Full Access
BA stands for Built-in Administrators

These settings allow the Administrators Full Access and also will be inheritable to children, both directories and files.

The second ACE is nearly the same except it uses GRGX (generic read, generic execute) instead of FA (full access) and it is indicated with a BU (built-in Users) instead of BA (built-in Administrators).

This makes up the ACL for an object or container. I will not go into all the details, but suffice to say that you can grant many different aspects such as reading or executing, deleting or modifying, to any group or user, with different ways of inheritance as well.

Now, Integrity Levels, which have been getting more exposure here as of late, are stored in the SACL. It uses what is called a Mandatory Label. Some refer to it as an SACE as well. Either way, it can be explicitly defined in the ACL of an object/container.

What M$ has done is to declare that anything, everything, unless explicitly declared by an SACL Mandatory Label, will have the Medium Integrity Level. This level is basically as strong as an Admin, but it cannot 'mess' with all things that are higher in Integrity than itself. If cannot stop a service or terminate a process that holds a higher Integrity Level. Well, that is a brief definition, because there are some exceptions. But for simplicity, almost everything that you will do will be at Medium. If it is at High, it has been assigned to be that way in the SACL somewhere.

You can apply a specific Integrity Level to an item yourself using icacls.exe. You might want to start Firefox.exe at a Low level instead of the default Medium.

Integrity Levels can also inherit to other processes or not (not sure about other files/directories yet). They can have 3 different 'flags' used with them also, as mentioned here before.
NR = do not accept read requests from lower-integrity processes.
NW = do not accept write requests from lower-integrity processes.
NX = do not accept attempts by lower-integrity processes to execute this object.

This seems a little ambiguous to me. I would have thought that the NX would work oppositely, but not so. To use that one, you would have to know of a program/file that you would not want to be executed by a lower level (such as the default Medium) process and you would have to ensure you set the Mandatory Label for that object to High (or higher than whatever level you want to restrict). If the Integrity Level can be set to a directory (which it can) and it will propagate itself to all children objects/containers (which I think it can) one might be able to explicitly declare that a certain directory, and everything in it, could be off limits to lower level objects.

Kees has laid forth many ideas as you are aware. One of them is to have a directory, maybe your download directory, that has the Execute permission denied for. Lets take a look at this for a moment. The order in which precedence takes place when the OS examines the ACLs are like this:
Denies are highest
Granted are lowest
Explicitly stated is judged before Inherited... things you make/create are examined before those that were assigned by inheritance.

You wonder, what are you talking about Sully! Well, it does have bearing, trust me. The C: (root) has certain rights and permissions on it, and for all things beneath it. Some directories such as the c:\Users directory are created to be independent of whatever C: is going to try an impose on it. But new directories that are created after the OS install will auto-inherit what C: told it to get. C: would be the Parent, passing on its genes to the child directory. C: is set up so that its genes, unless you or something interferes, will pass on to the Nth generation. Not only that, but those genes (rights/permissions) cannot be modified. You can add to them, but not modify the originals.

This is where the precedence comes in. If the genes of C: have told a folder you made for Users to have Generic Read and Execute rights, but you want to deny execute rights, you can create an additional ACE for your folder. It is an Explicit entry, and it takes precedence over the Inherited ones from the genes of C: . If you entry is to Deny GX, then when a User member attempts to execute, both the fact that it is a Deny and an Explicit place it in order before the Allows, and it is denied.

You wonder, so what? lol, me too. This means that you can use something like icacls to add your own Explicit right, and depending on the precedence order, it will be effective. But it is in ADDITION TO what is there already. In the past, some tools used would bork the rights because they would append to or replace rather than be an addition. It also goes the opposite way, where it is easier to remove your explicit right and without mucking up the original rights that were inherited.

Now, where am I going with this?

Kees implementation of denying execution from a downloads directory is straight forward, nothing strange. Using Integrity Levels to start something with lower rights than default is also easy to understand.

If you grasp how inheritance can effect children, pass along the genes of the parent.. if you grasp how denying execution or other rights will effect.. if you grasp the NR,NW and NX of Integrity Levels.. do you come up with any unique ideas on how to use those to your advantage while you are admin? Can you blend the allow/deny permissions along with the Integrity Levels, utilizing inheritance to an advantage. We don't want to set permissions on every item individually, we want them to get passed along in the genes. To use two different features to the fullest advantage.

I figured I would present this because there are a number of geeks here like myself who think off-the-wall, and my mind is fairly well numb with all of this right now. The more thoughts the better I think.

Of course, you might just be numb yourself now. I suggest a nice Hefeweizen to help with that, ice cold and tall

Sul.

 

Some ideas - assuming UAC is not disabled:

• Create a program that audits the admin account for permissions weaknesses. Existing programs that have been discussed in the past don't work for an admin-approval account because they assume the full admin token is being used.
• Create a program that makes it easy for a user to run programs that may be exposed to malicious content as low-integrity apps. This could either take the form of a predetermined list of apps - such as Firefox - or a generic solution that monitors the file and registry locations that are written in training mode. The necessary locations that can be written to would then be made low-integrity.
• Create a program that monitors whether apps that are desired to be low-integrity apps still are low-integrity apps. Program updates unfortunately can remove the low-integrity labels.
• Create or use a program that automates the creation of shortcuts to programs that the user wishes to launch without a UAC prompt. There already are several such programs - see https://www.wilderssecurity.com/showthread.php?t=279244.
• Create a program that allows the user to specify which folders can't be read by low-integrity programs. This can be accomplished with integrity levels.
• Advocate anti-execution protection in the form of SRP, AppLocker, Pretty Good Security, or using a HIPS such as Comodo Internet Security, as I've already shown. If using a HIPS, the user can optionally be prompted for files not in the whitelist.

 

I sort of understand this, but when you say to audit the account, are you meaning the actual ACL of the user or group only? Auditing that would not take much really, as it is pretty straight forward. Or perhaps you mean to audit all objects/containers that have been propagated. That would be quite a job. Not too hard to do to the original OS files if one desired to take the time to do so (it could be automated). It would really depend on the existence of the dacl Protect flag and inheritance. I would like to know more specifically what you mean in this if you could.

Hmm. You mean a pro-active program that monitors for the existence of such processes when they run? It might be easier to manage a list of applications that you have applied the IL to. For example, if you always used AppX to set an integrity level, it could keep track of what you were changing, and give the option to change back. That wouldn't be too awful hard to do. Starting a process with certain token is not hard either really. It is possible to change the IL of a process, but that code looks to be a bit tricky because there are stipulations that go with it.

Yes, good point. Process Explorer can do this, but a nice tool would be good too. A shell extension could do it with 7 because it could do nothing more than examine the mandatory label if there is one and display an icon in the context menu. Don't know if that would slow things down at all, but it is a good idea, one that I had thought of before. I don't know if there would be a reason to check both the mandatory label of the object as well as the process or not.

I haven't looked into this yet, but I will.

Yes, this would be easy to do, relatively. I am planning on including this in SAFE, as well as other options. Basically, all options I can include for IL I will.

You mean what exactly by advocate? To explain in a tool using some of these topics how to move past what the ACL/IL stuff does and include the more potent forms listed above? A little muddy on exactly what you mean here when you say to advocate.

Very nice reply. Full of technical mumbo jumbo, exactly the way I would have put it
Have you any thoughts on how inheritance to or from an IL might effect either to the good or bad? Privelage promotion is limited in some of IL, but the inclusion of inheritance when dealing with a parent directory is where I think some effect might be had.

I have also been wondering if the SID for the different Integrity Levels could possibly be used in an ACE. Don't know if it would do anything or not, but would be something to try that I am sure not many would approach, as it really goes against the meanings of everything, I think.

Thanks for the time to ponder that out.

Sul.

EDIT: BTW, you wouldn't happen to know where the .inf for windows 7 is that sets the real default security template would you? In XP you could use defltwk.inf, and it had many many entries. The one in win7 seems very small for a defualt template. Unless they have simply streamlined the inheritance or something. I am looking for the one that applies ACL to all files/dirs during OS install. There aren't even any SACL entries in that, and there are clearly some SACLs in place throughout the directory/file structure.

 

I mean check that the admin limited token can't write to c:\program files, most folders in c:\windows, registry HKLM, etc. - such as is covered in https://www.wilderssecurity.com/showthread.php?t=268435.

No. I'll give an example. When I made Firefox a low-integrity app, there were various manual steps involved. I am suggesting automating this task, maybe specifically for just a few chosen apps, or perhaps during a one-time training run that would then set the appropriate integrity labels.

I meant instead of fiddling with DACL, integrity levels, or the 1806 thing to control execution, instead maybe mention using AppLocker/SRP/HIPS to control unwanted execution in general.

I shouldn't try to think much about IL inheritance at this late hour, but I don't think I'd want low integrity levels to propogate any further than whatever the OS already does by itself.

You're welcome .

%windir%\inf\defltbase.inf?

 

Why would you want to use the No Execute Up flag on the Integrity Label? After examining the, I don't know what to call it, 'rights' of the generic flags (GR,GW,GX) there is a difference between XP and Vista/7. In XP the Generic Execute right provides only Read_Control and Synchronize. I don't exactly understand what that means yet, but when you look at Vista/7, the Generic Execute right provides Read_Control,Synchronize, Terminate and Query_Limited_Information. I am going to guess here and assume that you would want to use the NX flag on an IL to keep a GX ACE from terminating a process of higher IL (say that 5 times really fast lol). Perhaps Query_Limited_Information would also benefit from this type of restriction, don't know.

Anyway, I found it interesting that I can't find an NX flag (yet) in anything I have looked at with a Mandatory Label.

Actually I did find a couple mandatory labels in defltwk.inf and defltbase.inf. They are only assigned to a DRM and DRM Cache directory. More than that, I found you can use an IL on a registry key! I haven't seen that documented anywhere. Lucky me I guess, I know how to apply that to a registry key, but have yet to test anything. Still, the bulk of the entries that I expected to find in defltwk.inf are missing. Nowhere do I find the Mandatory Label for the items that are already elevated to High. I expect that it is the TrustedInstaller that is giving it this, but I don't see the mechanism on how it inherits this as the SACL is inherited it says.

For example, the process dwm.exe has integrity level of High. It has an SACL which is supposed to auto-propagate (S:AR with cacls and S:ARAI with icacls). Even more interesting is that chml shows it has no policy, yet it also shows the S:AI flag set. There is a difference between a blank policy and no policy, and these tools seem to be confused. Using ACLView, dwm.exe shows the owner as TrustedInstaller and an SACL for everyone (but ACLview does not show the ML). None of the tools show an ML at all, yet the process is running at High.

Since the SACL is showing it is inherited, you can look at System32, its parent directory. Here icacls, cacls, chml and ACLView all show no SACL at all, so it is not inheriting it from the parent directory. If you follow dwm.exe its parent process, it looks just like dwm.exe, where it has an SACL listed as S:AI or S:ARAI but again, chml shows it to be missing an SACL completely, called a "No Policy" case.

For you of only moderate geekness, this probably is pretty boring. But for you true nerds, this is strange. I would love for someone to show me where the initial trigger/setting is for these things, in SDDL syntax, preferably from an .inf file. I think I shall dig through the dvd contents to find some hidden prize.

It also appears than an unknown SID exists at times (with its SID listed) and then the same process can minutes later only show the SID without the 'unknown' listed in the title.

Excuse me, while I think out loud here. Perhaps someone else will find this as fascinating as I do and join in.

Sul.

 

Sul,

Since we had planned to automate the EMET hardening of a few browsers IE, Chrome/Iron, Firefox, Opera. You are allready asking in the user interface, which browsers should be mitigated with EMET.

Since IE, Chrome allready run with Low rights (at least the tabs), you could offer to policy sandbox FF also. This requires some additional directories to set with low rights also.

@Mr Brian could tell what the other directories are(see below)?
@Sul, this could easily be done by having an INI file for Firefox (and Opera), like you used for PGS.exe, would it?

@Wilders members
I do not know about Opera. Does it run Medium or Low rights? If it runs Medium rights, has any member tweaked it manaully to run with low integrity? Is so would you post which ones?

Thanks Kees

 

Regil

 

I was reading about this a few weeks ago and found this post that I think has a point: http://superuser.com/questions/3066...de-i-e-at-low-integrity-level#comments-128292

If it's possible to force FF to use

when in protected mode(like IE does) then that's good, otherwise it's better to use FF sandboxed or with NoScript I think?

 

I followed the instructions at http://www.victorc.org/2008/03/internet-explorer-7-protected-mode-vs.html. Because my Firefox profile is in a nonstandard location, I had to include that folder also.

 

https://www.wilderssecurity.com/showpost.php?p=1691539&postcount=9

 

Any browser, assuming it runs in a LUA, will run with Medium IL (Except Chrome, which will run with Low IL, at least in Vista and 7). Internet Explorer runs with Low IL only if UAC is enabled. It's UAC that forces IE to start with Low IL.

If you check with Process Explorer, you'll see that IE's main process runs with a Medium IL, while all sub-processes run in Low IL.

You can make any browser run with Low IL, but in Opera's case, if you try to run it as a different user, then it won't load at all. It won't have enough permissions.

I believe Chromium/Chrome would run just fine. The only issue I've found was that when running Chromium as a different user, since it won't install to %PROGRAMFILES% (It needs be manually placed there.), it won't run as a different user. One actually needs to have the web browser account with session started. But, an error message appears related to the "New Tab" feature asking to either disable or wait.

Google Chrome, runs fine as a different user, but only if using the enterprise package installer, which installs at system level (%PROGRAMFILES%). The same error related to the "New Tab" also appears, though.

I, then, checked with a Medium IL, and the same happened, so not related to ILs. So, my guess is that no problems of whatsoever would occur with Chromium/Chrome, if one decides to have some sort of sandbox, by using a different account for web browsing.

I know you didn't ask all that, but I did a *small* testing to verify all that stuff.

I still haven't tried to verify what causes the "New Tab" problem, though.

 

Yes, if using FF with Medium IL. Say you run FF, with Medium IL. There's a security vulnerability that ends up exploited and infects your system... I guess you can see the picture. If running with Low IL, it would be an entirely different scenario.

 

The SID of the Integrity Levels are as follows
Low (SID: S-1-16-4096)
Medium (SID: S-1-16-8192)
High (SID: S-1-16-12288 )
System (SID: S-1-16-16384)

Using icacls you can set a directory with an ACE to set Explicit permissions for those SIDs just like any other. For example

icacls <test dir> /deny *S-1-16-8192: (GR)

this will add an Explicit ACE to the <test dir> that denies Generic Read. If you then attempt to save/read etc to the <test dir> with a Low or Medium IL process, it is denied, insufficient permissions. If you try it with a High or System IL, it is allowed.

Can one use this to protect specific directories from any action that is deniable? Is it a replacement for the Mandatory Label? If you apply this, chml shows there is no Mandatory Label. It is an ACE. A Mandatory Label on a directory will not allow 'upward' action, that is a lower level process cannot read/write/execute a higher level process, depending on which flag you use. I did not like this, because you can't use it to basically block a lower IL from doing anything unless the objects it wants to mess with have a Mandatory Label, which most don't.

Using this method then, since everything runs with an IL, you can actively deny rights to lower IL processes. Not sure how robust it is or anything, just messing with stuff. But in theory, if most everything you personally start is at medium because that is the default, you could set a deny for medium SID to specific directories and be sure that unless you use something with a high IL it won't touch it.

More than likely though you would have your data directories with the deny ACE for low IL processes, and you would then make sure any potentially untrusted process would have a Mandatory Label of Low.

It all sounds a bit confusing for sure.

Sul.

 

You are correct. I even seen that when I downloaded chml a long time ago. Should have remembered. Thanks.

Sul.

 

Using chml you can set NoReadUp, NoExecuteUp, NoWriteUp to folders you consider sensitive. You also must set the sensitive folder(s) with High IL.

This way no process will be able to read (steal data), execute or write.

 

I need some help. I need to find a method to use an sddl syntax in an .inf file that will remove or create a null SACL. Setting the SACL with icacls or chml or other methods is easy enough to raise the IL to whatever level you prefer. However, this should be an explicit IL, not an inherited one, so it should be easily removed in the same manner an explicit DACL/DACE is. But no tools I can find give that option (chml might, but I am doing this all natively without a 3rd party tool).

So, if S : (ML ; OICI ; NWNXNR ; ; ; ME) (spaced for no smilies) sets an SACE mandatory label, how do you get rid of it?

Oh, almost forgot, there are other Integrity Levels, such as Medium Plus, Protected Process and Secure Process. I happened upon them but can't find any mention other than the one that I stumbled onto. Playing with them currently, but need to find a way to remove the IL just the way I found it rather than setting it back to Medium or something. Preferably anyway

Sul.

 

Sul,

Can't help you with your question. Just wanted to say you and Kees are really out of the box thinkers. Kees doing the initial hypothesis, you doing all the hard work. I really appreciate your quest.

When I understand your previous post correctly, in stead of a default deny of my download and mail directories, running my browser and mail with LOW integrity would do (Yes it has taken me nearly a week to finish the settings Kees propogated, it really is a deep dive into the mistique of your OS), because it could not read from/write to other directories.

May I throw in a user request (for SAFE-Admin)?

When you provide the option to run my browser (Iron does by default) and my mail (I have hacked Win7 so I could use winmail again of Vista ) with Low Integrity AND

The rest of my user directories are set to deny read/write by LOW integrity processes

THEN

With a LOW rights download directory and LOW rights mail directory I have everything covered. For ease of use I could define an extra UPLOAD directory (with LOW rights also) to put in attachements for E-mail or Uploads to websites likes Wilders.

Any change of adding this (this would add a policy sandbox around my E-mail and Browser, would even help against data theft)

Thanks

 

Might as well bring this up now, as it is going to be an issue I predict.

Is it better to keep LUA and UAC, with the Integrity Level of most everything you do at Medium (the default if not explicitly specified), including the shell? And just live with the UAC prompts - assuming you wish to be admin, I mean really be an admin and do admin things.

Or is it better to forget the LUA and UAC, and just get on with being an admin? The shell in this case runs at High Integrity.

This means, if you are LUA, most everything you do is Medium. When you were to use SAFE to set Firefox to Low IL, it will be unable to touch your Medium objects.

If you are without LUA, most everything you do is High because the shell is High and objects with no explicit IL will inherit the High level. The parent process gives the child the IL it has, and High is pretty much what you get on most things.

So we have a dilemma. If you don't want to be pestered by UAC then you have to declare everything you might want to run with less than High IL explicitly. That could be a lot. You cannot just put a Low IL on a document and then double click that to get Low. It will be High because the shell is High as admin. You would have to put a Low IL on notepad.exe for it to work.

If you are LUA and UAC, then you can set specific objects to a High level, and trust that your Medium level of things you run via the shell will not be able to touch it.

Conversely you can also set an ACE to deny the SID of an IL, which works conveniently.

So, when we talk of how to block execution, or set an integrity level, it makes a large difference on whether you are LUA or not.

Now, it is possible to use CreateProcessAsUser() and have a program that will start what you want with a specific security token or even (I think) a specific IL. This would be a temporary setting that would not remain after the process closes. But at that point it is not as convenient, and much like DropMyRights in how it is implemented.

I look at all the different angles of this, and come to the conclusion that people who want to run in LUA with UAC have a more convenient time because theirs is already a reduced token. But, they also have to learn to live with UAC. The shortcut methods that MrBrian has been talking about can help in that area.

I have been playing with disabling LUA/UAC, then making a copy of explorer.exe. The original explorer.exe I am making a Mandatory Label for IL of Medium, just like LUA has. Then the copy of explorer.exe I set to High IL, just like admin has. In this fashion the shell is medium, which is good, but can still restrict too much, but if you use the explorer.exe with High IL, you have the freedom again as an admin.

I don't know yet if there is a compromise that will work well or not. I would be interested to hear comments from those who might give Kees methods a trial run, on whether they want to be LUA/UAC of possible or just plain Admin. These ideas here offer some real variation depending on what you want, but I am only one person, and have many failings in coming from the viewpoint of LUA as I don't use it enough to really develop a fine tuned picture of what my issues with it would be. It is just too much for me with what I do, slows progress down extremely.

Sul.