Adding app_shim executable on Windows.

chrome/app_shim/app_shim_win.cc

Index: chrome/app_shim/app_shim_win.cc
diff --git a/chrome/app_shim/app_shim_win.cc b/chrome/app_shim/app_shim_win.cc
new file mode 100644
index 0000000000000000000000000000000000000000..84ddc45b10e7eb6555bb87a78d8dace24a4492f5
--- /dev/null
+++ b/chrome/app_shim/app_shim_win.cc
@@ -0,0 +1,65 @@
+// Copyright 2014 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include <string>
+
+#include "base/command_line.h"
+#include "base/files/file_path.h"
+#include "base/logging.h"
+#include "base/process/launch.h"
+
+#include <windows.h>
+
+namespace {
+
+// Return codes.
+const int kOK = 0;
+const int kNoProgram = 1;
+const int kLaunchFailure = 2;
+
+}  // namespace
+
+// This program takes a full Windows command line as command-line arguments, and

[jackhou1, 2014/10/26 22:56:09]

I remember discussing this a while back and saying that it should be fine to
just pass all the arguments. But if the set of switches we expect to pass with
this is small, maybe we should just parse them. That greatly limits what this
binary is capable of.

[Matt Giuca, 2014/10/27 00:16:16]

SECURITY: Do you think it is necessary to restrict the set of command-line
switches which the shim can pass to Chrome?

(This makes our life potentially harder because if we ever want to pass a new
argument to Chrome from the shim, we have to update the shim.)

[Will Harris, 2014/10/27 16:09:31]

+robertshield

The concern I have is that malware might piggyback on Chrome's digital signature
to load it's binaries via this signed executable, since AV typically uses
whether an executable is signed as a heuristic to determine how much to trust
it.  Robert, what do you think?

[robertshield, 2014/10/27 17:30:50]

I'd be much less worried if PATH_TO_CHROME_EXE stops being an argument and is
instead figured out by other means. There's a TODO below to do just this that
mentions  https://codereview.chromium.org/423293004/, landing that first sounds
like a good idea.

With the above change, I don't immediately see how a malware author would
benefit from running this vs. running Chrome directly. Presumably if an attacker
can already execute an arbitrary command line then trouble is already afoot. 

[Matt Giuca, 2014/10/30 06:39:05]

OK I'm using the registry to get the Chrome binary path. We still allow
arbitrary command-line flags. This shouldn't be a problem on Chromium because
I've got another patch to get the Chromium binary path from the registry. (It
still needs to be installed, but it does work for Chromium now.)

[robertshield, 2014/10/31 16:58:29]

Awesome, thanks!

+// executes it. It terminates as soon as the program is launched. It is intended
+// as a small shim for running chrome.exe; in particular, so that file types can
+// be associated with Chrome apps, with a custom name (and in some cases, icon)
+// rather than simply the name of the Chrome binary.
+//
+// Usage: win_app_shim -- PATH_TO_CHROME_EXE [CHROME_ARGS...]
+//
+// The -- is required if switches are to be passed to Chrome; any switches
+// before the -- will be interpreted by win_app_shim, and not passed to Chrome.
+int WINAPI WinMain(HINSTANCE instance,
+                   HINSTANCE prev_instance,
+                   char* /*command_line*/,
+                   int show_command) {
+  CommandLine::Init(0, nullptr);
+
+  // Log to stderr. Otherwise it will log to a file by default.
+  logging::LoggingSettings logging_settings;
+  logging_settings.logging_dest = logging::LOG_TO_SYSTEM_DEBUG_LOG;

[jackhou1, 2014/10/26 22:56:09]

I was under the impression stderr doesn't work on Windows and
LOG_TO_SYSTEM_DEBUG_LOG uses Sawbuck. But you're able to log to stderr with
this, then ignore this comment.

If you want to use Sawbuck, the instructions are here:
https://code.google.com/p/sawbuck/
You can take a look at how I've done it here:
https://codereview.chromium.org/423293004/diff/410001/chrome/app_installer/wi...

[Matt Giuca, 2014/10/27 00:16:16]

This is really only used to log the usage message below (which is only useful if
someone is trying to manually run the shim to understand how it works). It does
log to the command line output.

(I could just use printf... but this way seems neater.)

+  logging::InitLogging(logging_settings);
+
+  // Get the command line for the subprocess, consisting of the arguments (but
+  // not switches) to this binary. This gets everything after the "--". The
+  // first argument should be the location of the binary to run (full path to
+  // chrome.exe).
+  // TODO(mgiuca): Consider implicitly finding chrome.exe through the registry

[jackhou1, 2014/10/26 22:56:09]

Code to do this is here:

https://code.google.com/p/chromium/codesearch#chromium/src/chrome/installer/l...

I'm adding GetAnyChromeSxSPath() in https://codereview.chromium.org/423293004/
which should land "soon".

[Matt Giuca, 2014/10/27 00:16:16]

Acknowledged.

+  // somehow, instead of taking it as a command-line argument.
+  CommandLine command_line(CommandLine::ForCurrentProcess()->GetArgs());
+  if (command_line.GetProgram().empty()) {
+    std::string basename = CommandLine::ForCurrentProcess()
+                               ->GetProgram()
+                               .BaseName()
+                               .AsUTF8Unsafe();
+    LOG(ERROR) << "Usage: " << basename << " -- PATH_TO_CHROME_EXE [ARGS...]";
+    return kNoProgram;
+  }
+
+  base::LaunchOptions options;
+  if (!base::LaunchProcess(command_line, options, nullptr))
+    return kLaunchFailure;
+
+  return kOK;
+}