Over the past few weeks we have been posting blogs about the importance of limiting user account rights to only what is necessary for someone to do their job. Users should have all the rights necessary to do their job, but nothing less and certainly not any more. This includes local administrator rights. Only the people that absolutely need those rights should be given those rights. It is also our argument that fewer people actually need those rights that people generally believe. We’ve also posted a few times already on the dangers of giving people too many rights on a system. And remember, this applies to both Windows and Unix systems. Just because you can login as root, it doesn’t mean you should.

A question that comes up a lot though is, “What about software programs that require the user to be a local administrator in order to run the program?” Well, as I argued in a previous post, most programs don’t need the actual local administrator rights, they just need access to an object that the current user doesn’t have access too.

One of the most common objects that users often do not have the rights to are file system objects. Now in a perfect world, software developers would write their programs to only access portions of the file system that are accessible to everyday users. Or at a minimum, developers would document what file system objects they need to access to run their software. Of course reality says developers & documentation rarely go together. So how can a sysadmin figure this out for themselves?

In the old days, we could always use tools like Filemon & Regmon by Sysinternals to figure this out at a granular level. Unfortunately after Sysinternals was purchased by Microsoft, they combined the tools into one giant monitoring tool called Process Monitor. Don’t get me wrong, it’s a great tool and very capable of gathering system information. The trouble is it can be TOO powerful. Sometimes there are so many things happening on a system that it can be difficult to isolate just the file system events. So it would appear we need a different tool that we could use to monitor simply the file system object events to help us isolate where a user may need additional user permissions.

In searching for an app that would do this, I wanted something that would be isolated to file system objects, have the ability to start and stop monitoring on command, have the ability to reset logs, and have the ability to export data to a CSV or similar format so I could manipulate the data in Excel later if I needed to. Oh, and it would be nice if the tool were free. Even better would be if the app were a portable app that I could bring with me in my toolkit without having to install it on a machine. That’s when I found Moo0 File Monitor.

Let’s say I wanted to run Microsoft Word as my test case. I want to make sure I know all the file system objects that Word needs to access in order to run on my machine. To gather my data I would need to:

1. Close all open programs running on my computer (for the cleanest results).
2. Open Moo0 File Monitor and make sure it’s gathering data.
3. Clear the Moo0 logs to get a blank slate.
4. Open the program I want to test (such as Microsoft Word).
5. Close the program I’m monitoring to see files accessed on program exit.
6. Click the Stop button in Moo0 File Monitor to stop collecting data.
7. Save the Log File for later analysis.

The results of this process should be a list of files that were accessed during my session working with the software program in question. In this case when I tested it with Microsoft Word I received the following results:

Now we can use this information to examine all the file system object permissions that were listed in the log we created. Granted this can be a tedious process, looking at each set of permissions one at a time. However if you’re patient this can lead to giving people access to the objects they need to run their applications without giving them rights to all the files on the file system (ie. Local administrator). There may be more steps you need to take, such as looking at the registry or user rights as well, but this is often a good place to start and often solves the problem for you.

Hopefully tools like this make it easier for you to give people only the rights they need to do their jobs. If you have other tools that you think will help, send us a note on Twitter at @isaudit. We’d love to hear what’s worked for you as well.