Open Bug 710436 Opened 9 years ago Updated 6 years ago

Run update service under a virtual account or other more-limited account


(Toolkit :: Application Update, defect)

Windows 7
Not set




(Reporter: briansmith, Unassigned)



+++ This bug was initially created as a clone of Bug #710428 +++

Potentially, doing this would enable us to restrict the privileges of the *account* to a safer subset of the privileges that LocalSystem has. We already have written code to drop per-process token privileges (bug 708778).

(In reply to Ian Melven :imelven from bug 708778 comment 19)
> (In reply to Brian R. Bondy [:bbondy] from bug 708778 comment 15)
> > Brian Smith wrote:
> > > It seems like this patch does correctly drop the privileges that
> > > we can drop at the per-process level. However, we should follow
> > > up this work with some analysis of the per-user privileges (i.e.
> > > should we be running as LocalSystem or someone else) and
> > > per-directory privileges (including mandatory integrity control)
> > > to ensure that we are making the proper tradeoffs on those areas.

> My personal opinion is that if we want to not use LocalSystem and worry
> about what directories the process has access to, i would suggest focusing
> on an analysis of what it would take to move to an update process that
> doesn't require elevation of privileges, similar to what some other browsers
> have implemented.

(In reply to Brian R. Bondy [:bbondy] from bug 708778 comment 21)
> I should note that using a system or domain username is not possible because
> each would be a different username with a different password.
> The username/password must be set at service creation time
> (
> 85%29.aspx).
> So I think the only other options are:
> - LocalSystem
> - NT AUTHORITY\LocalService
> - AUTHORITY\NetworkService
> It seems there's also virtual accounts, but I don't know anything about them.
Is this bug talking about the update service being done as bug 481815?
You need to log in before you can comment on or make changes to this bug.