5 replies to this topic

[Mike Townsend]

I know that developing a self-patching game which is compatible with modern Windows UAC means accepting one of a number of tradeoffs, none of which are completely desirable, however the approach MWO takes at present is generally one of the least desirable alternatives.

The way it currently is: The launcher, patcher, and client all run with administrative privileges. This allows them to do virtually anything to a system. The client does not (should not/better not) require administrative access to the system (it should not be modifying the registry or changing installed contents or writing to non-user accessible locations.)

The issue is that processes started from other processes generally inherit the permissions of the launching process. It is possible to construct a security descriptor to launch a new process under which has different privileges, but consistently constructing one which accurately matches the current user is notoriously difficult. There are a few options for solving this problem:

1) Ensure game files which need to be modified by the patcher are not in a location that requires administrative privileges to write to. Variation a) Modify the permissions on the folder that the game is installed to so that the files can be altered by user-level processes. Variation b) Only install a minimal bootstrapping executable to an admin-only location.

Pros: Nothing needs elevation at all, neither the patcher nor the game. This means all users can always run the game, even if they do not have administrative permissions.

Cons: As all game files, and executable files pulled down by the patcher are located in a user-modifiable partition, any user level process can modify them, which presents an attack vector. This can be mitigated by careful checking of the signatures on any executable files or other critical files (using a cat file for validation, the way drivers do.)

Which location? If you install it in per-user app data, it prevents non-administrative users from modifying another user's game files, perhaps maliciously. But it means you must install the bulk of the game on a per-user basis. If you install to a shared location, then one user could modify the game in a way that another user would object to. Most reasonable mechanisms for choosing a location will make it relative to one of the specific system paths. Which means the majority of the data for the game isn't where a user expects it to be, which some portion of them will object to.

Attempting to modify the permissions on the install location generally won't work well. Certain Windows features enforce permissions on typical install folders (particularly program files.) Should the permissions be changed, the game will be unable to patch. Family Settings is a big offender here. Simply enabling it tends to reset the perms on program files for all users, even for games not checked by Family Safety.

In general, I don't think this is a great option unless the primary goal is to ensure that the game can successfully patch and execute without requiring any form of elevation. There is another way to achieve that effect, though,

2) Install a service which runs with SYSTEM permissions and delegate all file management to that service. This allows patching without elevation of any client-facing process. The biggest con, of course, is nobody wants every game they install to install a service, even one that is only run on demand. Some game services can get away with it (Steam) and some games which appeal to some audiences can also get away with it. But in general, this approach will be even more objectionable to more people that caching game files in a user-relative path per user. It is better than trying to modify folder permissions, though.

3) Install all files to a location which requires elevation to write to, and accept that users must elevate, but ONLY to patch. I personally believe (one of the variations of) this approach is usually the best tradeoff. Launch your bootstrap patcher under current user privileges and then do whatever checking you require to determine that the game is patched to the current level under user privileges. If no patch is required, launch the client under current privileges. If patching is required there are two main options:

a) Launch a second patcher executable which requires elevation and runs alongside the bootstrap executable, (UAC will prompt here) and intercommunicates with it. Have the patcher executable perform the patch and communicate success to the bootstrapper. Then have the process exit, and allow the user to launch the client from the bootstrapper (which is not running under elevated permissions.) Con: You're running two programs, and they run alongside each other, which can be weird depending on how it is presented to the user.

b) (This is the one I like best) put your patcher logic in a COM dll. COM allows an object to be hosted in a separate local process running under different privileges and provides a clean, familiar way for the processes to interoperate. It is essentially perfect for this sort of functionality. The primary drawback is that updating the registration for the server dll requires an installer pass. It should be possible for the dll to be updated, but the functionality should be simple enough that it doesn't need to, and security is probably better if you do updates to the COM object through msi anyway.) This approach generally has the best user experience (elevation for patch only, no elevation most of the time, appearance of a single, monolithic patcher application, generally compatible with any install location and Windows features such as Family Safety and antivirus software, one set of game files per system, installation of bulk of data in user-selected location) and the best security model (all files in administrative-writable location, absolute minimum surface area for code running with administrative privileges.)

Please take steps to ensure that the client runs under the current user's permissions. I know it may seem like elevation is only a minor annoyance for your users, but the last thing this (awesome, by the way) game needs is to become a target for malicious software.

[grayson marik]

Yes, he is right. You currently impose a security risk on our computers running everything as admin. Should be fixed indeed.

[Karl Split]

Hear hear, running under admin the whole time is really bad programming practice, im glad its not just me it ****** off.

And yes, I do know writing for UAC is a complete pita ive had to rewrite several programs because of it.

[Firewuff]

Problem with some of the above solutions are that they are worse than the current system.

Simply the laucher should run and check for patches. If and ONLY if it need to patch the game it asks for elevated privileges. Otherwise it doesn't need them. Once the patch is finished the process terminates and either it is manually relaunched or restarts automatically with normal privs

[Mike Townsend]

None of the above solutions are worse than the current system as they all reduce the attack surface, the severity of a successful attack, or both. I agree with you that suggestion 3a is one of the better ones, though I do think 3b, by virtue of not requiring a second launch, is overall the best compromise.

[Rigiroth]

honestly, I didn't read all of that. It'd be jiberish to me anyway. I can say, however, that I don't like having to run this program as an administrator. Their is just something unsettling about giving anyone, even a company, full access to my computer.