• <nav id="w5uq9"><big id="w5uq9"><noframes id="w5uq9"></noframes></big></nav>
        1. <th id="w5uq9"><track id="w5uq9"><sup id="w5uq9"></sup></track></th><em id="w5uq9"><acronym id="w5uq9"></acronym></em>
          <tbody id="w5uq9"></tbody>
            <legend id="w5uq9"></legend>

                  <button id="w5uq9"><acronym id="w5uq9"><u id="w5uq9"></u></acronym></button>

                  Changes to the design of CoApp

                  Jul 25 2011 by Garrett Serack @fearthecowboy

                  On Friday, we had a conference call to discuss a critical problem in the CoApp package manager.

                  ... when the user double-clicks on an a CoApp MSI, Windows Installer
                  elevates the installer process by switching to the LOCALSYSTEM (NT AUTHORITY\SYSTEM)
                  account, but actively removes a bunch of privileges that they didn't figure an
                  installer would need—specifically the ability to create symlinks has been
                  removed. Symlinks are a critical part of CoApp's design, and I'm not willing
                  to compromise the features thatrely on them...

                  Having looked at a few ways to overcome this limitation, we've pretty much settled on the idea
                  that we will split up some of the CoApp components into finer-grained pieces, and create a service that can perform
                  the requisite high-privilege operations that are needed to for CoApp to manage packages correctly.

                  This involves taking the CoApp Toolkit library, and splitting into two pieces--the components that we need for the higher-privileged service
                  (becoming the Toolkit Core) and components that have more general purpose (the Toolkit Client). The same goes for the the Engine library itself,
                  being split into the Engine Core, and the Engine Client. It's likely that most of the functionality will still reside in the
                  Engine core, and the Engine Client is there to facilitate the use of the Core.

                  A lightweight Win32 Service EXE is created to host the Engine Core itself.

                  service components

                  The communication between the client and service pieces of CoApp will use a simple bidirectional interface over named pipes, which will
                  make it pretty trivial to automate the CoApp engine from pretty much any language on Windows.

                  In some ways, this is actually a mixed blessing. Migrating part of CoApp itself into a Win32 service was a longer-range goal I've had, as it provides a few things:

                  -- Lets us create symlinks from an MSI install.

                  -- Limits even further the actual amount of code running at an elevated level.

                  -- Ensures all the network communication into userspace where it can happen at a lower privilege and take advantage of the user's network settings

                  -- we can decide what features "require" the user to be elevated (so, updates can be configured to install without direct user elevation)

                  This does of course come at an increased price; we not only need to do the appropriate refactoring necessary in CoApp engine and toolkit,
                  but now that we're adopting the Win32 Service model, we're going to also run a few components thru a very-fine-grained Security Audit.

                  A few links regarding Microsoft's Security Development Lifecycle:

                  SDL Website

                  SDL With Agile Development

                  Microsoft Security Development Lifecycle Guide v5.1