+++ 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 > (http://msdn.microsoft.com/en-us/library/windows/desktop/ms682450%28v=vs. > 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. > http://technet.microsoft.com/en-us/library/dd548356%28WS.10%29.aspx
Is this bug talking about the update service being done as bug 481815?
Depends on: 481815
You need to log in before you can comment on or make changes to this bug.