Manifests and requestedExecutionLevel

62 views
Skip to first unread message

Joseph M. Newcomer

unread,
Jul 9, 2007, 1:56:33 PM7/9/07
to
There is a dearth of documentation on manifests, such as the little inconsequential
details such as syntax, semantics, and methods for creating them. So I'm stuck, and I'm
looking for advice.

I have an app that has to run at the integrity level designated by
SECURITY_MANDATORY_MEDIUM_RID, because it wants to exchange PostMessages with another app
running at that same level. Right now, it always starts at SECURITY_MANDATORY_HIGH_RID.
While I can re-launch it using CreateProcessAsUser, it would be nicer if it could launch
itself at medium integrity level, and then in the unlikely case the co-process were
running high or low would a relaunch be necessary.

So the questions are (a) is this something the manifest will do for me? (b) if so, what is
the correct syntax for placing it in the manifest? and (c) given that the previous two
questions have positive answers, what is the technique of getting this added to the
manifest that is created for me automatically by VS2005?

If anyone has a pointer to documentation on manifests, I'd also be grateful. Searching
either the online MSDN or using google in general gets little snippets of pieces of
manifests, but no real documentation about them. I've downloaded the Vista SDK and
searched the MSDN library, but nothing is emerging as useful.
thanks
joe
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

BobF

unread,
Jul 9, 2007, 2:34:53 PM7/9/07
to
No answer for you Joe, but your questions prompted me to look around. I'm
very disappointed with the lack of manifest documentation ... and I trust
blogs less than wiki


"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:h6t49395k2e05vb7j...@4ax.com...

David Ching

unread,
Jul 9, 2007, 2:45:58 PM7/9/07
to
"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:h6t49395k2e05vb7j...@4ax.com...
> There is a dearth of documentation on manifests, such as the little
> inconsequential
> details such as syntax, semantics, and methods for creating them. So I'm
> stuck, and I'm
> looking for advice.
>

The best documentation for these things is blogs. For example
http://weblogs.asp.net/kennykerr/archive/2006/09/29/Windows-Vista-for-Developers-_1320_-Part-4-_1320_-User-Account-Control.aspx


> I have an app that has to run at the integrity level designated by
> SECURITY_MANDATORY_MEDIUM_RID, because it wants to exchange PostMessages
> with another app
> running at that same level. Right now, it always starts at
> SECURITY_MANDATORY_HIGH_RID.
> While I can re-launch it using CreateProcessAsUser, it would be nicer if
> it could launch
> itself at medium integrity level, and then in the unlikely case the
> co-process were
> running high or low would a relaunch be necessary.
>
> So the questions are (a) is this something the manifest will do for me?
> (b) if so, what is
> the correct syntax for placing it in the manifest? and (c) given that the
> previous two
> questions have positive answers, what is the technique of getting this
> added to the
> manifest that is created for me automatically by VS2005?
>


Kenny's article above makes it seem impossible to use a manifest to specify
a medium MIC. This will be the default for standard users but not for Admin
users (which will be High by default).

Kenny's article gives you a manifest. See the requestedExecutionLevel
section, but unfortunately there is no way to specify Medium MIC here. In
VS2005 project Properties, see the manifest tab and specify and Additional
Manifest.


-- David


Joseph M. Newcomer

unread,
Jul 10, 2007, 9:51:34 AM7/10/07
to
Yes, I have seen that article, but it is completely useless. It talks about gaining
administrator rights, but that does not appear to be the same as asking for a specific
integrity level, and it handwaves about the manifest without actually telling how to
create the manifest (there is no manifest I can find in my project, just the one that
appears to be created on-the-fly and therefore could not be modified by hand, even if I
could figure out what should go in it.

I wonder why manifests are so complex that the documentation was not delivered on the day
that manifests became a component of the system. There's Something Wrong With This
Picture. I should be able to go to the MSDN, open the section on manifests, and see the
complete documentation, syntax, semantics, and examples of use. Is it there? No. I
would like to point out that it is now 2007, and VS2005 has been out for two years. Is
anyone at Microsoft taking any responsibility for this fiasco?
joe

David Ching

unread,
Jul 10, 2007, 10:19:15 AM7/10/07
to
"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:cd3793tke1l13aop6...@4ax.com...

> Yes, I have seen that article, but it is completely useless. It talks
> about gaining
> administrator rights, but that does not appear to be the same as asking
> for a specific
> integrity level

Yes, as I said:

>Kenny's article above makes it seem impossible to use a manifest to specify
>a medium MIC. This will be the default for standard users but not for
>Admin
>users (which will be High by default).

To put it bluntly, I know of no way to use manifests to launch a process
with a guaranteed MIC of Medium. You have to use the CreateProcess API
variant you mentioned before.


> and it handwaves about the manifest without actually telling how to
> create the manifest (there is no manifest I can find in my project, just
> the one that
> appears to be created on-the-fly and therefore could not be modified by
> hand, even if I
> could figure out what should go in it.
>
> I wonder why manifests are so complex that the documentation was not
> delivered on the day
> that manifests became a component of the system. There's Something Wrong
> With This
> Picture. I should be able to go to the MSDN, open the section on
> manifests, and see the
> complete documentation, syntax, semantics, and examples of use. Is it
> there? No. I
> would like to point out that it is now 2007, and VS2005 has been out for
> two years. Is
> anyone at Microsoft taking any responsibility for this fiasco?

Joe, do you want help with this problem or just complain about it? Perhaps
the reason why there is no succinct doc on manifests is that they are simply
XML files. The contents are a collection of XML tags. You are asking the
equivalent of some XML primer that knows all possible tags you can possibly
put into your XML file. Impossible! Instead, each section (tag) of the
manifest is separately documented. For example, to specify elevation:

<v3:trustInfo xmlns:v3="urn:schemas-microsoft-com:asm.v3">
<v3:security>
<v3:requestedPrivileges>
<!-- level can be "asInvoker", "highestAvailable", or
"requireAdministrator" -->
<v3:requestedExecutionLevel level="requireAdministrator" />
</v3:requestedPrivileges>
</v3:security>
</v3:trustInfo>

and Common Controls 6:

<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="*"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>


To get this manifest into built into your .exe, I already told you:

Joseph M. Newcomer

unread,
Jul 10, 2007, 11:46:30 AM7/10/07
to
Yes, the problem is that it takes a while to get to the state where the level is
determined, and it involves a fair amount of work to launch a new process with the correct
level and get it back to the right state.

Seems like manifests aren't really well-thought-out in terms of what they can specify, and
certainly aren't documented.

I keep hoping that someone from Microsoft is reading these posts and takes back to the
appropriate groups that we are complaining about poor documentation.

See below...

****
No, I'm asking specifically for the list of tags that are used in manifests. That is a
finite and documentable set!
*****


>Instead, each section (tag) of the
>manifest is separately documented. For example, to specify elevation:
>
><v3:trustInfo xmlns:v3="urn:schemas-microsoft-com:asm.v3">
> <v3:security>
> <v3:requestedPrivileges>
> <!-- level can be "asInvoker", "highestAvailable", or
>"requireAdministrator" -->
> <v3:requestedExecutionLevel level="requireAdministrator" />
> </v3:requestedPrivileges>
> </v3:security>
> </v3:trustInfo>

*****
Hmm. So we have designations of integrity level such as "High", "Medium", "Low" and even
"System", but the keywords are "asInvoker", "higestAvailable" and "requireAdministrator",
and the correlation is obvious...

So where is the complete documentation of the manifest? I cannot find it in the MSDN. In
fact, a search in MSDN for "requestedExecutionLevel" reveals absolutely nothing usable,
such as a reference manual entry for this keyword. I did *that* search two days ago.
Neither the installed MSDN nor the online search reveal anything useful. The best
reference was to the beta 1 Longhorn distribution, although the details of the relevance
of a beta1 document to a final product is problematic.

Google sites were not that much more informative, giving at best snippets of manifests.
joe
*****


>
>and Common Controls 6:
>
><dependency>
> <dependentAssembly>
> <assemblyIdentity
> type="win32"
> name="Microsoft.Windows.Common-Controls"
> version="6.0.0.0"
> processorArchitecture="*"
> publicKeyToken="6595b64144ccf1df"
> language="*"
> />
> </dependentAssembly>
> </dependency>

*****
Hmmm. And how do I find out what each of these mean? Again, I should be able to find a
reference manual on manifests. The existing documentation is defined by a set of
incomplete examples, vague specifications, obsolete specifications (for example, one
specifies that "Win32" is the only allowable value (I wonder why Win64 is not a valid
operating system?), and only x86 and IA-64 are mentioned in another place, with no
indicating what is to be used for a 64-bit x86, so it is not clear if this is an oversight
or x86 applies to both 32-bit and 64-bit versions of the architecture. The effects of
various specifications are obscure, and overall there is nothing representing adequate
documentation anywhere I can find.
joe
****


>
>
>To get this manifest into built into your .exe, I already told you:
>
>> In
>>VS2005 project Properties, see the manifest tab and specify and Additional
>>Manifest.
>
>-- David
>

David Ching

unread,
Jul 10, 2007, 1:32:47 PM7/10/07
to
"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:lf879399hnga0ujpq...@4ax.com...

> Yes, the problem is that it takes a while to get to the state where the
> level is
> determined, and it involves a fair amount of work to launch a new process
> with the correct
> level and get it back to the right state.
>

Perhaps this check of state should be moved to the InitInstance() since it's
fairly critical functionality that can be determined if it's supported
without much fuss. Use IsUserAdmin().


> Seems like manifests aren't really well-thought-out in terms of what they
> can specify, and
> certainly aren't documented.
>
> I keep hoping that someone from Microsoft is reading these posts and takes
> back to the
> appropriate groups that we are complaining about poor documentation.
>

I agree MSDN is getting pretty sucky, and as MVP's it is our duty to tell
them so. I've done so on http://forums.microsoft.com where the important
people hang out. To be blunt, all your complaining on this newsgroup is
preaching to the choir and does no good because no one who can affect change
at Microsoft will read it here. On http://forums.microsoft.com, I've had
dialog with a MS Product Manager in charge of Windows Error Reporting and
complained that the Vista MSDN doc is totally inadequate, and MS seems to be
relying more and more on blogs and forum participation of key MS folks to
"document" the really important stuff. He agrees this is the case, and says
he will get published more info on the topic we were discussing.


> See below...


> No, I'm asking specifically for the list of tags that are used in
> manifests. That is a
> finite and documentable set!

Yes, perhaps, but since the info going into a manifest comes from diverse
groups within MS, they are probably not set up to organize the doc that way.


> *****
>>Instead, each section (tag) of the
>>manifest is separately documented. For example, to specify elevation:
>>
>><v3:trustInfo xmlns:v3="urn:schemas-microsoft-com:asm.v3">
>> <v3:security>
>> <v3:requestedPrivileges>
>> <!-- level can be "asInvoker", "highestAvailable", or
>>"requireAdministrator" -->
>> <v3:requestedExecutionLevel level="requireAdministrator" />
>> </v3:requestedPrivileges>
>> </v3:security>
>> </v3:trustInfo>
> *****
> Hmm. So we have designations of integrity level such as "High", "Medium",
> "Low" and even
> "System", but the keywords are "asInvoker", "higestAvailable" and
> "requireAdministrator",
> and the correlation is obvious...
>

The keywords unfortunately don't associate with MIC levels. That's the
issue. The keywords are mainly concerned about getting to an elevated state
and don't allow specifying a non-elevated state which is what you need.
It's unfortunate, but scarcely a documentation issue as the keywords are
very well documented.


> So where is the complete documentation of the manifest? I cannot find it
> in the MSDN. In
> fact, a search in MSDN for "requestedExecutionLevel" reveals absolutely
> nothing usable,
> such as a reference manual entry for this keyword. I did *that* search
> two days ago.
> Neither the installed MSDN nor the online search reveal anything useful.
> The best
> reference was to the beta 1 Longhorn distribution, although the details of
> the relevance
> of a beta1 document to a final product is problematic.
>
> Google sites were not that much more informative, giving at best snippets
> of manifests.

Joe, you're a smart guy, but now you're whining. In 5 minutes, I found:
http://msdn2.microsoft.com/en-us/library/aa905330.aspx which references a
Windows Help file that in the "Step 6: Create and Embed an Application
Manifest (UAC)" gives you all the gory details. Also, a good overview of
UAC is at http://msdn2.microsoft.com/en-us/library/bb206295.aspx which has
links to other things.

You don't much like it when people ignore your MVP essays, and yet you do
the same thing with these other well written articles, calling them
"irrelevant" and other such falsehoods. The Kenny Kerr article discusses
all these things in great detail and you seem to be the only one having
trouble understanding the definitions of the keywords. And I also cited the
CodeProject "UAC Elevator" article which is also great. You should have no
issue getting your problem solved with this info!

Like it or not, MSDN is being supplemented by other sources of info (very
accessible with google), and reading this material is required to stay
abreast of curent Windows development.

-- David


Pete Delgado

unread,
Jul 10, 2007, 2:20:51 PM7/10/07
to

"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:lf879399hnga0ujpq...@4ax.com...

> Yes, the problem is that it takes a while to get to the state where the
> level is
> determined, and it involves a fair amount of work to launch a new process
> with the correct
> level and get it back to the right state.
>
> Seems like manifests aren't really well-thought-out in terms of what they
> can specify, and
> certainly aren't documented.

Joe,
All aspects of UAC seem to be poorly documented at the moment. I personally
believe it is because UAC was not really ready at release time. You can
easily find some non-critical bugs. This leads me to believe that there are
potentially many critical bugs under the surface that people have yet to
find.

So far, I think that the majority of the "bugs" that I have found with UAC
have been due to the counterintuitive manner in which the various UAC
components work and fit together and the poor documentation.

For example, in your case, you are looking for a way to reduce the MIC level
via the manifest. It can be done using uiAccess="false" within the
requestedExecutionLevel element in the manifest. Unfortunately, by doing
this within the manifest you do not get the fine-grained control that you
most likely desire. You cannot set uiAccess="SECURITY_MANDATORY_MEDIUM_RID"
or anything that looks remotely like the constants used when
programmatically setting/querying the MIC level.


In short, I share your frustration!

>
> I keep hoping that someone from Microsoft is reading these posts and takes
> back to the
> appropriate groups that we are complaining about poor documentation.

I hope so...

-Pete


Joseph M. Newcomer

unread,
Jul 10, 2007, 5:24:25 PM7/10/07
to
Actually, I don't need administrative rights; as far as I can tell, I'm running as a
limited user. It's the integrity level, which I have to *reduce*, that is giving me
problems. Or is the integrity level what is being addressed by "administrative rights"?
It isn't clear, because it looks like two independent people are writing about this stuff.

If integrity level is directly correlated with the rights, then why are such meaningless
phrases as "asInvoker", "asAdministrator", etc. being used to describe what the API thinks
of as UIPI Low, Medium, and High? Is "asAdministrator" == "SECURITY_MANDATORY_HIGH_RID"?
Or not? It is not at all clear. Since I am not running as an administrator, I do not
want to see anything as "high". But I find that if I simply run my program from the
shell, as a limited user (as opposed to under VS, which *is* running as administrator)
then I *still* come up running as "High". So these levels apparently do *not* correlate
with concepts like "running as administrator".

If I can raise rights, why can't I specify that an app should run with *reduced* rights?

The problem is that I am currently running "High", so I can post messages to the "Medium"
app, but it can't post back to me. But finding the app cannot be done in InitInstance for
a variety of technical reasons, some of which I'm not at liberty to explain (NDA and all
that)--it requires user interaction. But once the user has designated the chosen target
app, an action that takes some effort, I have to relaunch if I discover that my rights are
not == the rights of the app. Note that they *must* be ==, so running as "administrator"
isn't right unless the target app is already at that level (again, I can't discuss the
real details) and it is unlike the target app will be at that level.

It's a real pain to debug, because after I launch under VS, then relaunch, I have to go
back to VS and attach to the new process. If VS had a way to specify the integrity level
for launch, this would solve much of my current problem, although not the long-term
deployment problem.
joe

*****
I find it impossible to get into those forums because the require lowering security on my
site, and that is not acceptable. The problem is the requirement of JavaVirus to allow
Passport login. I do not use Web sites that require client-side scripting (it is always a
mistake, anyway, to use client-side scripting--at least until I can create absolute
guarantees that no client-side script, under ANY conditions, EVER, can modify ANY
permanent state on my machine, and those guarantees do not exist. I have been taken out
twice by JavaVirus exploits, and now I have three levels of firewall to strip away every
known form of scripting before email and Web pages get to me).

If hanging out on those forums defines "importance", then I prefer to be "unimportant"
because I refuse to have my site taken out again.
*****


>
>
>> See below...
>> No, I'm asking specifically for the list of tags that are used in
>> manifests. That is a
>> finite and documentable set!
>
>Yes, perhaps, but since the info going into a manifest comes from diverse
>groups within MS, they are probably not set up to organize the doc that way.
*****

That suggests they have no idea what the issues are. I don't really care about
Microsoft's internal organization, I care about seeing a seamless end product, and if they
can't get internal groups to communicate, that represents a serious organizational
problem, but it is not an excuse for shoddy documentation.
*****


>
>
>> *****
>>>Instead, each section (tag) of the
>>>manifest is separately documented. For example, to specify elevation:
>>>
>>><v3:trustInfo xmlns:v3="urn:schemas-microsoft-com:asm.v3">
>>> <v3:security>
>>> <v3:requestedPrivileges>
>>> <!-- level can be "asInvoker", "highestAvailable", or
>>>"requireAdministrator" -->
>>> <v3:requestedExecutionLevel level="requireAdministrator" />
>>> </v3:requestedPrivileges>
>>> </v3:security>
>>> </v3:trustInfo>
>> *****
>> Hmm. So we have designations of integrity level such as "High", "Medium",
>> "Low" and even
>> "System", but the keywords are "asInvoker", "higestAvailable" and
>> "requireAdministrator",
>> and the correlation is obvious...
>>
>
>The keywords unfortunately don't associate with MIC levels. That's the
>issue. The keywords are mainly concerned about getting to an elevated state
>and don't allow specifying a non-elevated state which is what you need.
>It's unfortunate, but scarcely a documentation issue as the keywords are
>very well documented.

*****
Are they? Can you show me the page that says "Here is the correlation of keywords with
the actual integrity levels implemented by the operating system" followed by something
written in terms of SECURITY_MANDATORY_xxx_RID? I have no idea what these keywords mean,
and for that matter, only barely a grasp of what integrity levels do with respect to
concepts like being in the administrative group. This is what I mean by "good"
documentation. I spent several days trying to figure this out, and have still gotten
nowhere. Why is one set of documentation written in terms of the implementation and no
other set of documentation has any correlation to anything anyone can recognize as the
implementation?
*****


>
>
>> So where is the complete documentation of the manifest? I cannot find it
>> in the MSDN. In
>> fact, a search in MSDN for "requestedExecutionLevel" reveals absolutely
>> nothing usable,
>> such as a reference manual entry for this keyword. I did *that* search
>> two days ago.
>> Neither the installed MSDN nor the online search reveal anything useful.
>> The best
>> reference was to the beta 1 Longhorn distribution, although the details of
>> the relevance
>> of a beta1 document to a final product is problematic.
>>
>> Google sites were not that much more informative, giving at best snippets
>> of manifests.
>
>Joe, you're a smart guy, but now you're whining. In 5 minutes, I found:
>http://msdn2.microsoft.com/en-us/library/aa905330.aspx which references a
>Windows Help file that in the "Step 6: Create and Embed an Application
>Manifest (UAC)" gives you all the gory details.

*****
Actually, it doesn't. It merely says
"Create and embed an application manifest with your administrative applications. The
correct way to mark your applications is to embed an application manifest within your
program that tells the operating system what the application needs."

First, this is irrelevant to me because I am not writing an "administrative application".
And it does not refer me to a procedure I can use to actually do this. Since my goal is
to *lower* the level, so the app runs "more secure" than its launching process, I don't
see anything here. I, too, discovered this article in the first five minutes, read it in
some detail, but it is primarily concerned with issues of raising privilege and having
administrator rights, which has nothing to do with my problem. That was a couple weeks
ago, and I still can't find answers for the problem I have. And as far as "gory detail",
no, there isn't any detail about how to do this, just a handwave.

I also downloaded and read the help file, which doesn't. Help, that is. I read all 97
pages of it, and UIPI is what I'm concerned about, which is discussed on pp. 16-17, and
never again appears. There is nothing on the discussion of manifests. There is a lot of
discussion about how to write administrative installers, and masses of discussion on why a
program should not require administrative rights, but much of this seems to focus on ACLs,
and these do not appear to be correlated with CreateProcess lowering the integrity level.

I did see the section on adding manifests, and had forgotten that it was there; buried as
it is in 93 other pages of useless discussion, it was easy to misremember that there
actually was something of value there. Especially given how long ago I read it. Now, if
I were worrying about installs and patches, and doing aministrative things, this article
would have been incredibly useful, but since I'm not concerned at all about any of those
things right now, it really didn't help.
*****


>Also, a good overview of
>UAC is at http://msdn2.microsoft.com/en-us/library/bb206295.aspx which has
>links to other things.

****
Since I am not a game developer, it never occurred to me to look at something in a domain
far outside anything I was concerned about. Now that I've read it, it appears to be
equally irrelevant, alas. These articles keep addressing issues that would be important
in another context (and several months ago, I incorporated some of these contents into my
Systems Programming course) but none of them appear to address the issue I have to face,
which is how to arrange that the process I create comes up as the invoker but with the
SECURITY_MANDATORY_MEDIUM_RID attribute set. It may be that there is such a fascination
with administrative rights issues that something this simple is not addressed, but it is
not really possible to discover that.
joe
*****


>
>You don't much like it when people ignore your MVP essays, and yet you do
>the same thing with these other well written articles, calling them
>"irrelevant" and other such falsehoods. The Kenny Kerr article discusses
>all these things in great detail and you seem to be the only one having
>trouble understanding the definitions of the keywords. And I also cited the
>CodeProject "UAC Elevator" article which is also great. You should have no
>issue getting your problem solved with this info!

****
Actually, I have no idea if they ignore them or not. I toss them out there, and people
are free to read or ignore them as they see fit. I would not at all be offended if people
ignored them. But I get enough feedback from the people who don't ignore them that I
believe there is actually a readership out there, so I keep writing them. I'm not sure
I've ever made a statement that "I don't like it much" if people ignore my articles,
because that is never a criteria I've used or even been concerned about.

If an article doesn't solve my problem, and doesn't give me insight to the domain of the
problem, it is irrelevant. As I said, if I were concerned about how to write an
installer, or an ActiveX control, or many other details covered in those 97 pages of help
file, it would be an excellent article. But for solving my problem, the only relevant
pages were really pp16-17, and they were VERY relevant, and were the key to getting the
code to work at all. But the rest of it is currently irrelevant. Saying something is
irrelevant doesn't mean it is bad, it means that it isn't relevant to solving my problem.
If my problem were different, then I'd have a different opinion. Saying an article is
irrelevant is not a falsehood, it is a statement that of those 97 pages, 95--no, make that
94, because of the manifest embedding page--have nothing to do with the problem I'm trying
to solve. And that last page would only be relevant if there was somehting I could put in
the manifest to cause my program to be launched with the SECURITY_MANDATORY_MEDIUM_RID
property. I really don't plan to write an ActiveX control, for example, or write an
application program that would write to HKLM, or write to the Program Files directory; and
although that article had a lot of relevant stuff to say that is now in my Systems
Programming course, it is irrelevant relative to my current problem!

I have not ignored these articles; in fact, I read some of them months ago, and re-read
them or found new articles in the last week, The Kerr articles are what I have based my
current code on (decoding his odd collection of classes to create the real code was a
pain, by the way, but I can't use any class code like this due to contractural issues, so
in fact my code is a blend of his code and two other articles). You cited the codeproject
article when I first asked, and I read it carefully, and it is great, but it doesn't make
things clear about what "integrity levels" are as compared with "account privileges".

In fact, right now I've got a couple interesting programs that deal with all kinds of
token issues, but I'm not finding out critical information I need to complete them,
because there seems to be several different ways of referring to the same issue, depending
on which group is writing about them. Or perhaps they really *are* writing about
different things; I can't tell.

Currently, I'm using his articles to solve my problem *after* launch, but what I want to
do is have a solution that solves the problem *at* executable launch, and that does not
seem to be possible. But what is frustrating is that the fragmentation of documentation
into blog sites, MSDN, codeproject, etc. makes any search for it nearly impossible.

(It is also worth pointing out that many "original" articles have copied the code from
other articles, including the bugs! So there are perhaps 20 articles, all of which have
the same bug in them, and no credit is given to the original bug-free article by Kerr, for
example, even though it is clear that it is his code).

I am having trouble understanding the definitions of the keywords because there are two
uncorrelated sets of names and somehow I'm supposed to magically infer that one means the
same as the other.

I've not been sitting here hoping documentation would magically fall into my lap. I've
spent days reading this stuff, only to find that after I've read it, I *still* have no
idea how some of it fits together, and neither the MS documentation nor the blogs are
resolving the discussion. The documentation is incomplete, and the blogs somehow assume
that I've memorized all of the available documentation. And a few really good articles,
like Kerr's, solve a particular problem (rather nicely) but it isn't quite the problem I
need to solve.

(I used to say that Microsoft documentation was "all of the facts and none of the truth",
but my recent excursions into UAC and manifests makes it obvious that even getting the
facts down has now escaped the ability of the documentation people).
joe
****


>
>Like it or not, MSDN is being supplemented by other sources of info (very
>accessible with google), and reading this material is required to stay
>abreast of curent Windows development.
>
>-- David
>

Joseph M. Newcomer

unread,
Jul 10, 2007, 5:38:34 PM7/10/07
to

*****
I wouldn't care if it was the same constants, or even some *combination* of values, as
long as there was a handy-dandy decoder ring that said "If you want to launch with the
equivalent of CreateProcessAsUser with a SECURITY_MANDATORY_MEDIUM_RID level, you would
set..."

By default, the uiAccess level is "false", according to the documentation I've found, and
it talks about the "privileged" UI, which I don't care about. I have no uiAccess
specification in the pre-generated manifests, which means I should be gettng the default
anyway. I wouldn't want to raise it. The program I'm working on is not supposed to be
able to touch windows that a limited user can't touch.

But the handy-dandy decoder ring isn't there, or at least I can't find it, and everything
I find talks about how manifests can be used to *raise* the level, and in any case they
are more concerned with gaining administrative privileges (which I don't need) instead of
dealing with what appears to be an orthogonal concept, the integrity level.

I've been writing little programs to explore the various concepts and uses of 'tokens',
but I find serious holes in the documentation at critical points. It hasn't helped that I
can only find this documentation in the online MSDN, since apparently the Vista
documentation isn't in the post-Vista MSDN library I installed locally.
joe
*****


>
>
>In short, I share your frustration!
>
>>
>> I keep hoping that someone from Microsoft is reading these posts and takes
>> back to the
>> appropriate groups that we are complaining about poor documentation.
>
>I hope so...
>
>-Pete
>

David Ching

unread,
Jul 10, 2007, 8:13:03 PM7/10/07
to

"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:n1q793po9glnpmvos...@4ax.com...

Dude, it's not that hard. Clearly if you need to send/post messages between
the two apps, then they must be running at the same MIC (Low, Medium, High,
System). What I suggest is you break your program into two .exe's. The
first one runs at the default MIC (or High, if necessary) and the user then
selects the target app somehow. Then this first one uses
CreateProcessAsUser to launch the second .exe with the MIC of the target one
(using the techniques described at
http://www.codeproject.com/vista-security/VistaElevator.asp).

FWIW, when people talk about standard user priviledge, that is Medium MIC.
And Admin user priviledge is High MIC. This is from Kenny Kerr article.
http://weblogs.asp.net/kennykerr/archive/2006/09/29/Windows-Vista-for-Developers-_1320_-Part-4-_1320_-User-Account-Control.aspx

-- David


Joseph M. Newcomer

unread,
Jul 11, 2007, 12:43:30 AM7/11/07
to
See below...

****
I had already proposed this to the customer (last week) and it was apparently rejected. I
had used a two-process scheme some years ago which worked very well. I had asked if named
pipes would solve the problem, and did not get a positive response. So I'm stuck with the
current single-executable model. The existing app is a single executable, and runs on
various other versions of Windows, so I think this is not an option they'll entertain.
*****


>
>FWIW, when people talk about standard user priviledge, that is Medium MIC.
>And Admin user priviledge is High MIC. This is from Kenny Kerr article.
>http://weblogs.asp.net/kennykerr/archive/2006/09/29/Windows-Vista-for-Developers-_1320_-Part-4-_1320_-User-Account-Control.aspx

****
This explains integrity levels as if they are an orthogonal concept to ACL-related
privileges. The code from this article has proven to be very useful, and forms the core
of most of what I've done. I've also used this article as the basis for my Token Explorer
program, which I'm working on in parallel. It seems to indicate that integrity level is
still independent. I had first assumed that because I was running VS as an admin (the
recommended practice) that my debugged process was of course running as admin, so I went
outside VS and launched the exe from the normal (non-elevated) shell, and it *still*
seemed to come up with Integrity Level High, making it unable to communicate as desired.
joe

*****

David Ching

unread,
Jul 11, 2007, 7:54:24 AM7/11/07
to
"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:gan893dl11esbs8ud...@4ax.com...

> I had already proposed this to the customer (last week) and it was
> apparently rejected. I
> had used a two-process scheme some years ago which worked very well. I
> had asked if named
> pipes would solve the problem, and did not get a positive response. So
> I'm stuck with the
> current single-executable model. The existing app is a single executable,
> and runs on
> various other versions of Windows, so I think this is not an option
> they'll entertain.

It sounds like if you can originally start your process with Medium MIC,
then you would be happy for the most part. So why don't you create a small
.exe which simply starts your main .exe with Medium MIC (using the
CodeProject UAC elevator techniques)?

Now once your process is running with Medium MIC, then it asks user to
select "target app", and if in the rare case this target app is running at
High MIC, then you need to shutdown your process and restart it at High MIC.
Since you already have the small .exe running (see above), which can wait
for your main app to quit using WaitForSingleObject(), you can return an
error code saying it needs to be restarted at High MIC and exit, then your
small .exe wakes up and restarts your main app with High MIC (again using
CodeProject UAC elevator techniques).

Since this approach essentially keeps your main exe the same (the code to
find the target app and the code that then does something with it is still
kept in the same exe), your customer might go for it. Because on the
down-level Windows, the small .exe can be ignored and only the main exe
used, same as it always was.

>>
>>FWIW, when people talk about standard user priviledge, that is Medium MIC.
>>And Admin user priviledge is High MIC. This is from Kenny Kerr article.
>>http://weblogs.asp.net/kennykerr/archive/2006/09/29/Windows-Vista-for-Developers-_1320_-Part-4-_1320_-User-Account-Control.aspx
> ****
> This explains integrity levels as if they are an orthogonal concept to
> ACL-related
> privileges. The code from this article has proven to be very useful, and
> forms the core
> of most of what I've done. I've also used this article as the basis for
> my Token Explorer
> program, which I'm working on in parallel. It seems to indicate that
> integrity level is
> still independent.

Yes, I think the problem here is both you and I struggle with ACL concepts,
and then there is this new MIC thing which UAC is based on. Here is my
concept of MIC. Kenny seems to be clear that UAC is in addition to ACL and
is a simpler concept. It compares an exe's MIC with the MIC of the
resources it desires to interact with, and if it is less, it can't access
the resource. Examples of resources which have MIC's are other exe's (to
determine if you can send them messages, hook them, etc.), folders (to
determine if your executable can write into c:\, for example), etc.

There are 4 levels of MIC, and only the middle 2 are accessible by us.
Those are High and Medium.

High == "run as administrator" == "elevated"
Medium == "run as standard user" == "non-elevated"

By default, an .exe's MIC is the same as the process which started it, e.g.
as if the manifest had:

<v3:requestedExecutionLevel level="asInvoker" />

The manifest has the capability of telling Vista that it needs to be started
with High MIC:

<v3:requestedExecutionLevel level="requireAdministrator" />


What is missing is the capability of telling Vista that it needs to be
started with Medium MIC. This was clearly spelled out in the CodeProject
Vista Elevator article, where he went through great pains to start the app
with Medium MIC (non-elevated). The first attempt used the Windows
scheduler (which runs at Medium MIC), but this has problems for Installer
apps that, because they are elevated, run in the Admin account, and there
the Windows scheduler runs at High MIC, so any process it starts is also run
at High MIC. His second attempt is available from his website (not
CodeProject), and I haven't looked there to see how he worked around this.

Anyway, I could be wrong, but I don't think you need to be concerned about
ACL's. It gets confusing because ACL's are used when you talk about "Admin
priviledges", and now High MIC is also called "Run as Admin". But they are
not the same, since even a user account with Admin priviledges normally
starts processes with Medium MIC (and not High MIC or "Run as admin").
Kenny Kerr's article explains all this much better than I just did, but
maybe this explanation gives the essence that then makes Kerr's article
understandable.

> I had first assumed that because I was running VS as an admin (the
> recommended practice) that my debugged process was of course running as
> admin, so I went
> outside VS and launched the exe from the normal (non-elevated) shell, and
> it *still*
> seemed to come up with Integrity Level High, making it unable to
> communicate as desired.

What do you mean, "seemed to" come up with Integrity level High? Did you
check using Process Explorer (as described in the Kenny Kerr article) that
it was running at High MIC even when launched from Explorer? If it is
running at High MIC (btw. MIC == "Integrity Level") then either it has a
manifest with the

<v3:requestedPrivileges>
<!-- level can be "asInvoker", "highestAvailable", or
"requireAdministrator" -->
<v3:requestedExecutionLevel level="requireAdministrator" />
</v3:requestedPrivileges>

or Explorer (the Invoker) is itself elevated. Again, check with Process
Explorer.

In addition, unless you are using an external .manifest file, your app's
manifest is in the .exe. Open the .exe within Visual Studio and check it's
resources and see what is in the manifest.


Good luck,
David


Joseph M. Newcomer

unread,
Jul 11, 2007, 9:03:38 AM7/11/07
to
That is what I've had to do, since 99% of the time the co-process will be running as
Medium. It has been running for several days that way. But this violates some issues
about simplicity of installation and use that the customer finds desirable criteria. So
the preference was to launch it as Medium, and if the user selects a target window which
is High, restarting it, reloading the list of windows, re-selecting the previous
selection, resetting the selected options,setting the focus to whatever control the user
had been focused on, and then communicating with the target process. I'm trying to avoid
the complexities of state maintenance. The code for the state maintenance is complex, and
there is still negotiation about what should happen if a 'high' window is selected.

We've been down several design paths, and all the obvious ones (such as the one you
suggest, which is the one which has been running since last week) are producing concerns
about whether or not they are acceptable. Most of these problems would go away if there
were a simple way to launch at Medium MIC and be done with it. There is even a suggestion
that talking to a High MIC process would simply be forbidden, so I was tasked with
investigating ways to cause this launch to occur at the correct level in the first place,
without using the current intermediate launch mechanism (which, as I said, is a real pain
to debug with). And that's where the frustration has come in: there's enough missing
information to make it difficult to determine if the lack of information is due to lack of
functionality, inadequate documention, or whatver. For example, although I find that for
an actual 64-bit build the processorarchitecture="amd64", the documentation CLEARLY states
the ONLY two allowable values are "x86" and "ia64". Given how long the AMD64 has been out
and running Windows, do you think I give much credibility to documentation that has
clearly not been updated in 3 or 4 years? Could I tell from reading the documentation
that the statement "The only allowable value is win32" has any meaning in a win64
environment? (It turns out that inspection of a win64 manifest shows that it really does
say "win32", even though this makes no sense). So the documentation is misleading,
confusing, and certainly out of touch with reality. For all I know there have been
massive changes in what manifests do, and there is no real source of authoritative
information.

Because of the need to restore state transparently, the executable cannot remain the same,
which is a situation we are trying to avoid.
joe

David Ching

unread,
Jul 11, 2007, 10:13:33 AM7/11/07
to
"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:9oj993h418ra3r0mp...@4ax.com...

> That is what I've had to do, since 99% of the time the co-process will be
> running as
> Medium. It has been running for several days that way. But this violates
> some issues
> about simplicity of installation and use that the customer finds desirable
> criteria.
>

Well then, what if you create a single .exe that is responsible for
launching a second .exe at Medium MIC. The trick is the second .exe is
stored in the resource, so at startup, it is extracted from the resource and
placed in either the same folder or a temporary one for which write access
is obtained. Then the second .exe is launched at Medium MIC. All of this
transparent to the user. It's what SysInternals does by self-extracting a
device driver at startup and dynamically installs it (I think it is either
for Process Explorer or Process Monitor).

I think you need to set your customer's expectation that a second .exe is
necessary to ensure Medium MIC. That is clearly established by now. They
can do whatever tricks like the above to make it more paletable, but they
need a second .exe.


> There is even a suggestion
> that talking to a High MIC process would simply be forbidden, so I was
> tasked with
> investigating ways to cause this launch to occur at the correct level in
> the first place,
> without using the current intermediate launch mechanism (which, as I said,
> is a real pain
> to debug with). And that's where the frustration has come in: there's
> enough missing
> information to make it difficult to determine if the lack of information
> is due to lack of
> functionality, inadequate documention, or whatver.

It's clearly a lack of functionality as the CodeProject UAC Elevator article
makes readily apparent.


> For example, although I find that for
> an actual 64-bit build the processorarchitecture="amd64", the
> documentation CLEARLY states
> the ONLY two allowable values are "x86" and "ia64". Given how long the
> AMD64 has been out
> and running Windows, do you think I give much credibility to documentation
> that has
> clearly not been updated in 3 or 4 years? Could I tell from reading the
> documentation
> that the statement "The only allowable value is win32" has any meaning in
> a win64
> environment? (It turns out that inspection of a win64 manifest shows that
> it really does
> say "win32", even though this makes no sense). So the documentation is
> misleading,
> confusing, and certainly out of touch with reality. For all I know there
> have been
> massive changes in what manifests do, and there is no real source of
> authoritative
> information.
>

Yeah, well undocumented Windows is a way of life. Windows still remains one
of the best documented API's of all time, in no small part to MSDN but also
due to 3rd parties feretting out the details and presenting them, as Kenny
Kerr did.

There is no documentation like the source code in terms of authority. Have
you considered using a Service Support Incident that comes with your MSDN
subscription to see what MS has to say about this?


-- David


David Ching

unread,
Jul 11, 2007, 10:24:18 AM7/11/07
to
"David Ching" <d...@remove-this.dcsoft.com> wrote in message
news:hA5li.19878$2v1....@newssvr14.news.prodigy.net...

> Well then, what if you create a single .exe that is responsible for
> launching a second .exe at Medium MIC.

The author of UAC Elevator, Andrei Belogortseff, wrote another article
http://www.codeproject.com/vista-security/RunNonElevated.asp that describes
injecting a DLL into Explorer (which runs at Medium MIC) and sending a
private message to the DLL to get it to launch an app with Medium MIC. This
is instead of using the Vista scheduler.

-- David


Pete Delgado

unread,
Jul 11, 2007, 3:36:42 PM7/11/07
to

"David Ching" <d...@remove-this.dcsoft.com> wrote in message
news:Qx3li.21339$RX.1...@newssvr11.news.prodigy.net...

> There are 4 levels of MIC, and only the middle 2 are accessible by us.
> Those are High and Medium.

This is technically incorrect as you are free to create your own integrity
levels. (ref: p34 of Writing Secure Code in Windows Vista by Michael Howard
& David LeBlanc)

> Anyway, I could be wrong, but I don't think you need to be concerned about
> ACL's.

You are correct to a point. Once the MIC level restriction (write down, no
write up) is satisfied, then you may have the opportunity to be concerned
about ACLs! ;)

> In addition, unless you are using an external .manifest file, your app's
> manifest is in the .exe. Open the .exe within Visual Studio and check
> it's resources and see what is in the manifest.

Note that the Visual Studio 2005 linker will place a default manifest file
within your application if you do not specify one within your project.

-Pete


Pete Delgado

unread,
Jul 11, 2007, 4:28:05 PM7/11/07
to

"David Ching" <d...@remove-this.dcsoft.com> wrote in message
news:hA5li.19878$2v1....@newssvr14.news.prodigy.net...

> Yeah, well undocumented Windows is a way of life. Windows still remains
> one of the best documented API's of all time, in no small part to MSDN but
> also due to 3rd parties feretting out the details and presenting them, as
> Kenny Kerr did.

Given that UAC is one of the core functionality enhancements within Windows
Vista, I think that Joe and I are being perfectly reasonable by expecting
that the API and behaviour of all aspects of UAC functionality should be
documented prior to release. While I am deeply indebted to people like Kenny
Kerr, Maarten Van De Bospoort and Michael Howard, it seems to me that there
should be no need for all their efforts if the documentation were up to
standard.

-Pete


David Ching

unread,
Jul 11, 2007, 4:46:59 PM7/11/07
to
"Pete Delgado" <Peter....@noads.net> wrote in message
news:%23JR3cn$wHHA...@TK2MSFTNGP06.phx.gbl...

>
> Given that UAC is one of the core functionality enhancements within
> Windows Vista, I think that Joe and I are being perfectly reasonable by
> expecting that the API and behaviour of all aspects of UAC functionality
> should be documented prior to release. While I am deeply indebted to
> people like Kenny Kerr, Maarten Van De Bospoort and Michael Howard, it
> seems to me that there should be no need for all their efforts if the
> documentation were up to standard.
>

I agree such expectations are reasonable, I'm just saying it's never been
any different so it's not like we as Windows developers should feel entitled
to it.

-- David


David Ching

unread,
Jul 11, 2007, 4:50:09 PM7/11/07
to
"Pete Delgado" <Peter....@noads.net> wrote in message
news:OUybvK$wHHA...@TK2MSFTNGP03.phx.gbl...

>
> This is technically incorrect as you are free to create your own integrity
> levels. (ref: p34 of Writing Secure Code in Windows Vista by Michael
> Howard & David LeBlanc)
>

Really? Thanks, I hadn't known that. I don't have that book handy. If I
do create my own integrity level, is there an easy way to specify it in
ShellExecuteEx() or CreateProcessAsUser()?


> Note that the Visual Studio 2005 linker will place a default manifest file
> within your application if you do not specify one within your project.
>

Yeah, that's why I told Joe to look in the .exe and see which one was
actually there. Since the manifest option is titled "Additional manifests"
it's also unclear to me whether the one you specify here is supplemented by
an auto-generated one or not?

-- David


Joseph M. Newcomer

unread,
Jul 12, 2007, 2:34:35 AM7/12/07
to
That book just arrived from Amazon, and as soon as I get the rest of this program working
it is my topmost-important book to read. I've now got enough working that we can
concentrate on functionality for a week or so.
joe

Pete Delgado

unread,
Jul 12, 2007, 10:24:37 AM7/12/07
to

"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:7qib931bij03kr0n2...@4ax.com...

> That book just arrived from Amazon, and as soon as I get the rest of this
> program working
> it is my topmost-important book to read. I've now got enough working that
> we can
> concentrate on functionality for a week or so.
> joe

Joe,
Unfortunately there is only a single chapter dedicated to UAC and it is
rather light. It seems to me that there needed to be a longer discussion
about the ramifications of some of the choices a developer might have with
respect to the various configurable aspects of UAC. In addition, there
seems to be a lot missed with respect to OTS elevation and the system policy
settings that affect the style of elevation.

As a result, the blogs that I had referenced in a post several weeks ago
remain valuable sources and the information is not duplicated within the
Howard book.

-Pete


Joseph M. Newcomer

unread,
Jul 12, 2007, 3:48:13 PM7/12/07
to
Thanks. That's disappointing news.
joe

Joseph M. Newcomer

unread,
Jul 12, 2007, 3:51:31 PM7/12/07
to
As far as I can tell there is no "easy" way to incorporate it into CreateProcessAsUser;
the Kerr article is one of the best, but it is hard to penetrate his classes. One of the
alternative techniques is to create a SID string of the form
S-1-16-integritylevelhere
and use ConvertSidStringToSid to convert it, so I used that idea from a different article
(16 is SECURITY_MANDATORY_AUTHORITY, and 1 is a Revision 1 SID). The integrity level is
represented in decimal.
joe

Joseph M. Newcomer

unread,
Jul 12, 2007, 3:52:53 PM7/12/07
to
Which is an unfortunate comment on corporate culture: "Poor documentation was acceptable
20 years ago, so it should be perfectly acceptable today" is not a good rationale.
joe

David Ching

unread,
Jul 12, 2007, 10:12:11 PM7/12/07
to

"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:jc1d93tvh9avm4glm...@4ax.com...

> As far as I can tell there is no "easy" way to incorporate it into
> CreateProcessAsUser;
> the Kerr article is one of the best, but it is hard to penetrate his
> classes. One of the
> alternative techniques is to create a SID string of the form
> S-1-16-integritylevelhere
> and use ConvertSidStringToSid to convert it, so I used that idea from a
> different article
> (16 is SECURITY_MANDATORY_AUTHORITY, and 1 is a Revision 1 SID). The
> integrity level is
> represented in decimal.

Thanks. But now that I have a string representing the SID, how do I use it
to start a process at that integrity level?

-- David


Pete Delgado

unread,
Jul 13, 2007, 10:52:29 AM7/13/07
to

"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:3b1d93plg4cagd1ha...@4ax.com...

> Thanks. That's disappointing news.
> joe

Joe,
In case you haven't seen it...

-Pete

http://msdn2.microsoft.com/en-us/library/bb625964.aspx

David Ching

unread,
Aug 2, 2007, 8:03:09 PM8/2/07
to

"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:7qib931bij03kr0n2...@4ax.com...

> That book just arrived from Amazon, and as soon as I get the rest of this
> program working
> it is my topmost-important book to read. I've now got enough working that
> we can
> concentrate on functionality for a week or so.

Hey, I just stumbled on this
http://wiki.helpware.net/tiki-index.php?page=VistaUAC

Manifest to mark an application with the requested execution level
<requestedExecutionLevel
level="asInvoker|highestAvailable|requireAdministrator"
uiAccess="true|false"/>
- level --
asInvoker-The application runs with the same token as the parent process
highestAvailable-The application runs with the highest privileges the
current user can obtain.
requireAdministrator-The application runs only for administrators
- uiAccess --
true-The application is allowed to bypass UI protection levels to drive
input to higher privilege windows on the desktop. This setting should only
be used for UI Accessibility applications.


So if you include in your manifest the uiAccess=true, then you should be
able to launch your app with Medium MIC and have it call SendMessage() to
High MIC apps!

-- David


Reply all
Reply to author
Forward
0 new messages