Adding method to create process using LowBox token in sandbox code.

sandbox/win/src/app_container.h

 // Copyright (c) 2012 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.
 
 #ifndef SANDBOX_WIN_SRC_APP_CONTAINER_H_
 #define SANDBOX_WIN_SRC_APP_CONTAINER_H_
 
 #include <windows.h>
 
 #include <vector>
@@ skipping 14 matching lines @@
 // process.
 class AppContainerAttributes {
  public:
   AppContainerAttributes();
   ~AppContainerAttributes();
 
   // Sets the AppContainer and capabilities to be used with the new process.
   ResultCode SetAppContainer(const base::string16& app_container_sid,
                              const std::vector<base::string16>& capabilities);
 
-  // Updates the proc_thred attribute list of the provided startup_information
-  // with the app container related data.
-  // WARNING: startup_information just points back to our internal memory, so
-  // the lifetime of this object has to be greater than the lifetime of the
-  // provided startup_information.
-  ResultCode ShareForStartup(

[rvargas (doing something else), 2015/02/27 20:16:34]

I know I asked you to remove this, but after talking with cpu yesterday we
concluded it was better to keep the old code as it was, at least for a while
(especially after the realization that the lowbox token is not really related
with a regular AppContainer).

How about we separate the two concepts so that:

SetAppContainer() is needed for a normal AppContainer
HasAppcontainer() returns true for that normal AppContainer (and false for
lowbox)

SetLowBox(app_container_sid) is what we use for the lowbox path
HasLowBox() as named

GetCapabilities() works for both cases.

----------

This means that TargetPolicy gains a new method besides SetAppContainer:
SetLowBox(sid)... and we enforce that lowbox and appcontainer policies are
mutually exclusive.

Another option would be not to add SetLowBox() and instead redefine TokenLevel
to have something below USER_LOCKDOWN... that seems actually cleaner but a
little more dangerous so we can just leave that for later.

-      base::win::StartupInformation* startup_information) const;
+  bool HasAppContainer() const;
 
-  bool HasAppContainer() const;
+  // Returns security capabilities structure, which is populated when you call
+  // SetAppContainer.
+  const SECURITY_CAPABILITIES& GetCapabilities() const;
 
  private:
   SECURITY_CAPABILITIES capabilities_;
   std::vector<SID_AND_ATTRIBUTES> attributes_;
 
   DISALLOW_COPY_AND_ASSIGN(AppContainerAttributes);
 };
 
 // Creates a new AppContainer on the system. |sid| is the identifier of the new
 // AppContainer, and |name| will be used as both the display name and moniker.
 // This function fails if the OS doesn't support AppContainers, or if there is
 // an AppContainer registered with the same id.
 ResultCode CreateAppContainer(const base::string16& sid,
                               const base::string16& name);
 
 // Deletes an AppContainer previously created with a successfull call to
 // CreateAppContainer.
 ResultCode DeleteAppContainer(const base::string16& sid);
 
 // Retrieves the name associated with the provided AppContainer sid. Returns an
 // empty string if the AppContainer is not registered with the system.
 base::string16 LookupAppContainer(const base::string16& sid);
 
 }  // namespace sandbox
 
 #endif  // SANDBOX_WIN_SRC_APP_CONTAINER_H_