Coapp engine engine as a service redesign

fearthecowboy edited this page Jul 22, 2011 · 1 revision

##Problem:

The problem, is that 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.

The only way we can get from that crippled LOCALSYSTEM account to a real LOCALSYSTEM account is to create a Win32 service, and spin it up (which we can actually do from that crippled LOCALSYSTEM account), and have it do the work we need done.

Options: Cheat -- build small service that we install as localsystem to do that small bit of dirty work Change -- so we don't use that. ggrrrr.. Not without sacrificing important features Fix CoApp Engine -- split the engine into two parts: - Engine "Service" which handles all the high-privilige work - Engine "Client" which runs as the regular user, handles networking and files

  • Reduce the size of the Service engine to a minimum; - Do a full security audit on the Service engine. - create a communications interface to the Service that the client can talk to. - have the Client engine talk to the Service over the interface - the engine "client" handles all the networking and off-box communication, so we don't have to have painful workarounds for proxies and local network resources

Actual Good Points:

        - Lets us create symlinks from an MSI install.
        - Limits further the actual amount of code running at an elevated level.
        - Moves all the network communication into userspace where 
        - we can arbitrarily decide what features "require" the user to be elevated 
          (so, updates can happen without user elevation)

Components:

        * Core Toolkit -- Common code shared amongst all components
        * Engine Service -- Win32 service that handles high-privilige operations, core logic.
        + Client Toolkit -- Common code shared amongst low-privilige apps 
            - Handles all off-box communications(SMB/http/https)
        + Engine Client  -- Code to talk to Engine, low-privilege operations
        + Client Apps -- 
            (Tray App, Mini-Installer, Command Line , GUI Package Manager)
        + Bootstrapper -- Runs as crippled LocalSystem, installs the service components.

Questions:

        - Communication Channel between userspace and the Engine Service?
            - how do we handle asynchronous requests/responses?
            - multiple clients connecting concurrently?
            - remote management in the future?
            - make technology agnostic? (no .NET-only features?)
            
        - How much stuff in the Engine Service
        - Where do we draw the line for what "requires" user elevation?
        - Who will participate in security audits?
        - Other help (gui/clients)?
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.