2

Is it possible to see which permissions an application installer needs while it is running? I'm thinking sort of like a debugger or monitor to see what windows is checking for.

The situation is that we have an in-house developed windows app that updates itself regularly, and users have always been running under local admin accounts so that this update works. I find that to be a bit too much for my liking and would like to grant only the necessary permissions for this installer to work properly.

It may be impossible for me to change the behavior of the installer, or to even examine the steps that it is taking directly.

Is it possible to see exactly which permissions windows is stopping at while running this installer?

I've been able to determine that the installer needs write access to C:\Windows and C:\Windows\System32 because of specific error messages, but after that, it stops at a rather generic "You do not have access to make the required system configuration modifications. Please rerun this installation from an administrators account."

EEAA
  • 108,414
  • 18
  • 172
  • 242
Tim Lehner
  • 255
  • 2
  • 9
  • in this case you are lucky that you only have one application to deal with and was created in house, I had to do this for 1000's of third party apps. Microsoft does have tools for this but its been a 5+ years since I've used it, one tool in particular acted as a shim for misbehaving apps, bad things is I can't remember its name... – tony roth Aug 02 '12 at 21:01

3 Answers3

3

Yes, it's called Process Monitor from SysInternals (now part of MS), and it's a godsend.

Also, get your management to buy off on this idea, and make your devs/QA test this crap as regular users on test systems, so that they're not making you do more work to fix their mistakes.

mfinni
  • 35,711
  • 3
  • 50
  • 86
  • 1
    `so that they're not making you do more work to fix their mistakes.` Not to mention pawning off their mistakes on every other sysadmin in the world unfortunate enough to use shitty software that doesn't adhere to the principle of least privilege: http://en.wikipedia.org/wiki/Principle_of_least_privilege – HopelessN00b Aug 06 '12 at 04:09
1

Rather than figuring out the perfect permissions, you could launch the update process using the "runas" utility

Bob
  • 597
  • 2
  • 8
  • So, you're still giving the desktop users "local admin" permissions to do that. – mfinni Aug 03 '12 at 17:06
  • local admin within a specific process whose source is obscured from the desktop users. The users can't launch runas, and the escalated privilege ends with the completion of the update process. What's the rub? – Bob Aug 03 '12 at 17:08
  • So, you're suggesting that Tim, rather than the end user, be the one running the update process? In the question, Tim says that the app updates itself, which means that the app is running as the user. – mfinni Aug 03 '12 at 17:13
  • I'd suggest that the app spawn a separate update process, providing the necessary privileges by means of Runas. Most of the time, aren't you using a separate Windows process for the actual update anyway? – Bob Aug 03 '12 at 17:16
  • I dunno - I'm not a developer :-) But regardless, how do you get the "runas" working, in the session of the unprivileged end user? What user it runas-ing? – mfinni Aug 03 '12 at 17:34
  • Follow the link above and it explains it. – Bob Aug 05 '12 at 02:49
  • @mfinni That's not necessarily the case. You can deploy a RunAs shortcut containing cached administrator privileges, if you need to obscure the local admin password from the end users. – HopelessN00b Aug 06 '12 at 04:12
0

OK, so other than the idea of Process Monitor to find the required permissions, or RunAs to provide the administrative permissions, you could always run the updater in a system context to avoid the whole mess, couldn't you?

Use AD startup scripts or software installation settings to run the updater under a system context, or instead of setting the updater service to run under user context, change it to run as NTAUTHORITY\Local Serveice or SYSTEM. Also easily achieved through a GPO or script.

HopelessN00b
  • 53,385
  • 32
  • 133
  • 208