Let's take a look at the security involved here. Can the BA currently
execute arbitrary processes with elevation with only one UAC prompt? Yes,
there are two ways. One way is to hack the .exe manifest to require
administrator. There's nothing we can do to prevent this. (Well, I guess
the engine could refuse to run in this scenario but would we really
implement that?) The second way is to put an EXE package in the chain that
simply runs the executable specified in its command-line arguments. We
can't prevent this either without crippling EXE packages.
I think we already agree that there are legitimate use cases for a Bundle
to launch an executable elevated without a UAC prompt. Neither of the
current ways are secure. Running the BA elevated is asking for trouble.
When you include an EXE package in the chain that will run anything you
tell it, that means that compromising the BA gives an attacker the ability
to run elevated code, which means game over. The question is what's the
best way for the Bundle to securely run an elevated process after calling
Apply?
I don't like the suggestion to include an EXE package in the chain that is
hard coded to launch the "real" .exe and make it easier to execute it
outside of Apply. It's a slippery slope to the EXE package above that will
run anything. It's a "fake" package: it's not installing anything. I
think it's unnecessary and undesirable to separate the logic of which .exe
to run from the BA.
Ideally, we would require that the elevated process was installed onto the
system from a package in the chain. I don't think that's possible. For
example, let's say the Bundle installs a third party product which is
deployed through an EXE package and the Bundle wants to launch an .exe
that's installed by that EXE package. Henning mentioned that he's using an
.exe to work around IIS's decision to require admin privileges to read the
IIS config, another reason not to fixate on the idea of requiring that the
target .exe comes from a package in the chain. The more barriers that we
put in front of this new feature, the more we push the Bundle to the two
insecure ways described in the beginning. This is why I proposed to make
the Bundle register the .exe files that it wants to run at compile time.
The bundle can run any .exe on the machine (as long as it registered it at
compile time), because that's what it can do already. This way, the engine
can verify that the target .exe is exactly the same as it was at compile
time, making it much more secure.
This feature was opened more than a year before Burn was released. Please
help me get this designed in time to get into 3.9 (since it sounds like
this is the last opportunity to get it into 3.x).
On Tue, May 13, 2014 at 11:44 AM, Sean Hall <[email protected]> wrote:
> My problem with requiring that .exe is somewhere in the chain is how you
> would enforce that. For example, what if your Bundle A has Bundle B as an
> EXE package, and you want to run an .exe inside an MSI that's in Bundle B?
>
>
> On Mon, May 12, 2014 at 10:10 PM, Bob Arnson <[email protected]> wrote:
>
>> The use case is to run a config tool (that requires elevation) without
>> leaving the bundle running in the background. You can do that today with a
>> simple .exe that launches the config tool and exits. The goal of the
>> feature request is to make that easier. I'm concerned about putting the BA
>> in charge of it, because of the potential for abuse and the additional
>> effort required.
>>
>> That said, I can see that (1) the feature might need more flexibility
>> than you can get from just bundle authoring and (2) I'm usually in favor of
>> the approach you're suggesting (adding engine primitives the BA can use).
>>
>> What if the focus is on an executable installed elsewhere in the chain?
>> (i.e., no separate payloads, only a component GUID/file id from an
>> installed package)
>>
>
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
WiX-devs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-devs
