In message <um6x8AsWHHA.3652@TK2MSFTNGP04.phx.gbl> "Joseph Geretz"
<jgeretz@nospam.com> wrote:

>> Fair enough -- Do you have a better suggestion that maintains backwards
>> compatibility?

>
>Yes, as I suggested:
>

>>> actually detecting operations which require elevation ...

>
>But that's too tricky?

How would you suggest doing that?

The problem is that the security token needs to be assigned at runtime,
an app cannot be elevated while running. This is required, otherwise a
non-elevated app could hook into an app which it suspects might become
elevated in the future, and once the elevation happens, the non-elevated
app would have full elevated privileges.

Worse, consider what would happen to a regular user (non-administrator)
who happened to be running a program that needed to be elevated part way
through. The program would not only received an administrator token,
but also an entirely different security context -- The new context might
not even have the ability to read it's own EXE, or the files it was
reading previous to the elevation.
--
Insert something clever here.

> How would you suggest doing that?

By scanning the executable at load time.

- Joseph Geretz -

"DevilsPGD" <spam_narf_spam@crazyhat.net> wrote in message
news:2b9fu2hru9o7usfeqb2cvmvk9icf1rc4a0@4ax.com...

> In message <um6x8AsWHHA.3652@TK2MSFTNGP04.phx.gbl> "Joseph Geretz"
> <jgeretz@nospam.com> wrote:
>

>>> Fair enough -- Do you have a better suggestion that maintains backwards
>>> compatibility?

>>
>>Yes, as I suggested:
>>

>>>> actually detecting operations which require elevation ...

>>
>>But that's too tricky?

>
> How would you suggest doing that?
>
> The problem is that the security token needs to be assigned at runtime,
> an app cannot be elevated while running. This is required, otherwise a
> non-elevated app could hook into an app which it suspects might become
> elevated in the future, and once the elevation happens, the non-elevated
> app would have full elevated privileges.
>
> Worse, consider what would happen to a regular user (non-administrator)
> who happened to be running a program that needed to be elevated part way
> through. The program would not only received an administrator token,
> but also an entirely different security context -- The new context might
> not even have the ability to read it's own EXE, or the files it was
> reading previous to the elevation.
> --
> Insert something clever here.

Joseph

Those guidelines are general. If you don't see your specific issue addressed
in those documents, go to the developer forums, and ask your specific
question there. This is where all of the Microsoft developers, who wrote
most of the code for Vista, post answers to messages. I'm sure you can find
the soulution you are looking for on those forums. Start with the Where Is
the Forum For...?

MSDN Forums:
http://forums.microsoft.com/MSDN/default.aspx?SiteID=1



--

Ronnie Vernon
Microsoft MVP
Windows Shell/User


"Joseph Geretz" <jgeretz@nospam.com> wrote in message
news:%234Jx6bAXHHA.3948@TK2MSFTNGP05.phx.gbl...

> Hi Ronnie,
>
> Unless I missed it, the questions of installing an ActiveX EXE is *not*
> addressed in any of the links you reference. Your allusion to developers
> who are not following 'Microsoft guidelines' is nothing more than
> apologetics for Microsoft's abysmal practice in this regard. Microsoft has
> changed the rules of the game radically, without fully considering all of
> the implications and without providing developers with adequate
> documentation.
>
> So again, I challenge you. Where is the documentation, the guideline if
> you will, on how to install an ActiveX EXE using a custom action from
> within an MSI setup file? Not from within an EXE setup file, that will
> work - but from an MSI setup file. Although, why an MSI should operate
> under different rules than the equivalent EXE is beyond me, but no doubt
> you can cite a 'guideline' which will explain this to us?
>
> - Joseph Geretz -
>
> "Ronnie Vernon MVP" <rv@invalid.org> wrote in message
> news:eYuo$17WHHA.896@TK2MSFTNGP05.phx.gbl...

>> Joseph
>>
>> Here are some links to get you started.
>>
>> Developer Best Practices and Guidelines for Applications in a Least
>> Privileged Environment:
>> http://msdn2.microsoft.com/en-us/library/aa480150.aspx
>>
>> Look near the bottom of this link for a downloadable help file on
>> developing ActiveX Controls for Vista.
>> Windows Vista Application Development Requirements for User Account
>> Control:
>> http://msdn2.microsoft.com/en-us/library/aa905330.aspx
>>
>> Security in Longhorn: Focus on Least Privilege:
>> http://msdn2.microsoft.com/en-us/library/aa480194.aspx
>>
>> You can access the Vista Developer forums here and dialog with other
>> developers who doing the same work that you are.
>> http://msdn2.microsoft.com/en-us/win.../aa905020.aspx
>>
>> Google Search:MSDN2
>> http://tinyurl.com/2kq25h
>>
>> --
>>
>> Ronnie Vernon
>> Microsoft MVP
>> Windows Shell/User
>>
>>
>> "Joseph Geretz" <jgeretz@nospam.com> wrote in message
>> news:%23FwS7x2WHHA.1180@TK2MSFTNGP05.phx.gbl...

>>>> the developers to follow the current Microsoft standards for writing
>>>> applications and programs for Vista.
>>>
>>> All right, I'll call you on it, and if you can help me out or point me
>>> in the right direction, I'll be grateful for your help.
>>>
>>> What are the guidelines for deploying and registering an ActiveX EXE on
>>> Microsoft Vista with UAC enabled?
>>>
>>> Simple question. I'm one of the devleopers you speak of, and I very much
>>> wish to follow the new programming guidelines. It's one thing to talk
>>> about guidelines, and quite another to actually define and publish them.
>>> I've been Googling and asking questions for days now, trying to find out
>>> what the guidelines are for deploying ActiveX EXE with UAC enabled. So
>>> please, what are the guidelines?
>>>
>>> Thanks,
>>>
>>> Joseph Geretz
>>> Microsoft VPD
>>> Very Pissed Developer!
>>>
>>> "Ronnie Vernon MVP" <rv@invalid.org> wrote in message
>>> news:C98CB19D-5BA8-494A-8484-B0A0D3798E7B@microsoft.com...
>>>> Adam
>>>>
>>>> I don't see anything in that quote that conflicts with the statement
>>>> that you see as an excuse. The users are the people who need to put
>>>> pressure on the developers to follow the current Microsoft standards
>>>> for writing applications and programs for Vista. These program
>>>> developers have had more than ample time to respond to the many calls
>>>> by Microsoft to learn and follow the new programming guidelines.
>>>>
>>>> We all knew that the changes in Vista would be "high impact issues" but
>>>> the overwhelming reason was the state of the security in previous
>>>> versions. UAC is not going to go away in SP1.
>>>>
>>>> --
>>>>
>>>> Ronnie Vernon
>>>> Microsoft MVP
>>>> Windows Shell/User
>>>>
>>>>
>>>> "Adam Albright" <AA@ABC.net> wrote in message
>>>> news:rbh7u2tmq0skhhhc1nb1pmakaop83p4hmn@4ax.com...
>>>>> On Mon, 26 Feb 2007 23:15:53 -0600, "Robert Firth"
>>>>> <webmaster@winvistainfo.org> wrote:
>>>>>
>>>>>>Magic keywords "setup", "update"...
>>>>>>
>>>>>>Old installers were not written properly to ask for proper permissions
>>>>>>to
>>>>>>install an app (admin privileges).
>>>>>
>>>>> The old it ain't Microsoft's fault excuse. Interesting, that seems to
>>>>> be more a MVP excuse considering what high ranking Microsoft officials
>>>>> admit to:
>>>>>
>>>>> Item: Jesper Johansson, a senior security strategist in the Security
>>>>> Technology Unit at Microsoft, admits that the current implementation
>>>>> of UAC presents too many privilege escalation pop-up prompts, but he
>>>>> insists there is a method to the apparent madness.
>>>>>
>>>>> "Unless we get feedback on what works and what does not, we can't fix
>>>>> it. If you disable critical technologies that we are trying to get to
>>>>> work, we can't fix them," Johansson said in a blog entry. "That means
>>>>> that, yes, some things will be annoying and not work quite right in
>>>>> the final release, unless people work with us to fix them," he added.
>>>>>
>>>>> Item: Microsoft has granted, in a roundabout way, that Vista has 'high
>>>>> impact issues.' It has put out an email call for technical users to
>>>>> participate in testing Service Pack 1, due out later this year, which
>>>>> will address 'regressions from Windows Vista and Windows XP, security,
>>>>> deployment blockers and other high impact issues.'
>>>>>
>>>>> It's hard to know whether to be reassured that Service Pack 1 is
>>>>> coming in the second half of 2007, and thus that there is a timeframe
>>>>> for considering deployment of Vista within businesses, or to be
>>>>> alarmed that Microsoft is unleashing an OS on the world with "high
>>>>> impact issues' still remaining, according to Microsoft.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>

>>

>
>

That's not really possible. Windows can't tell what a program does be
examing the exe. While some things could of course be gleaned, like declared
API calls, the program may jump to the API address or use the ordinal rather
than use symbolic names.

MS solution is .NET programming language with it managed code model.

Why don't you drop the manifest into the exe.

"Joseph Geretz" <jgeretz@nospam.com> wrote in message
news:eJLLFNOXHHA.3980@TK2MSFTNGP02.phx.gbl...

>> How would you suggest doing that?

>
> By scanning the executable at load time.
>
> - Joseph Geretz -
>
> "DevilsPGD" <spam_narf_spam@crazyhat.net> wrote in message
> news:2b9fu2hru9o7usfeqb2cvmvk9icf1rc4a0@4ax.com...

>> In message <um6x8AsWHHA.3652@TK2MSFTNGP04.phx.gbl> "Joseph Geretz"
>> <jgeretz@nospam.com> wrote:
>>

>>>> Fair enough -- Do you have a better suggestion that maintains backwards
>>>> compatibility?
>>>
>>>Yes, as I suggested:
>>>
>>>>> actually detecting operations which require elevation ...
>>>
>>>But that's too tricky?

>>
>> How would you suggest doing that?
>>
>> The problem is that the security token needs to be assigned at runtime,
>> an app cannot be elevated while running. This is required, otherwise a
>> non-elevated app could hook into an app which it suspects might become
>> elevated in the future, and once the elevation happens, the non-elevated
>> app would have full elevated privileges.
>>
>> Worse, consider what would happen to a regular user (non-administrator)
>> who happened to be running a program that needed to be elevated part way
>> through. The program would not only received an administrator token,
>> but also an entirely different security context -- The new context might
>> not even have the ability to read it's own EXE, or the files it was
>> reading previous to the elevation.
>> --
>> Insert something clever here.

>
>

In message <eJLLFNOXHHA.3980@TK2MSFTNGP02.phx.gbl> "Joseph Geretz"
<jgeretz@nospam.com> wrote:

>> How would you suggest doing that?

>
>By scanning the executable at load time.

To what end? How do you determine if an EXE will desire to write to
Program Files pragmatically? Or whether it will want to write to a
portion of the registry which is off-limits without elevated privileges?

I suspect you'd find that any similar solution would be even more buggy,
and there would be just as many complaints of "Why can't Vista figure
out that setup.exe is an installer and needs elevated privileges"
--
Insert something clever here.

"Joseph Geretz" <jgeretz@nospam.com> wrote in
news:OTF78yeWHHA.5068@TK2MSFTNGP03.phx.gbl:

> AAAAAAaaaarrrrggggggghhhhh!!!!!!
>
> It's the NAME of the executable, AutoUpdate, which makes Vista THINK
> (assuming
> that this brain-dead OS is capable of such a thing) that the process
> needs to run elevated.
>
> kpg, this explains your issue as well; In your case it's that third
> app in the chain which has the magical term 'update' in it, for me
> it's the second. Who the !#$%@$# slapped this so-called OS together,
> J.K. Rowling?

wow...just got back to this thread.

Unbelievable!

Reminds me of the time a when I had a component named bridge.dll -
Windows defender thought it was spyware based solely on it's name - because
there was some malware that used a bridge.dll file - how about checking
signatures?

whatever...

kpg