|libove||PSI for users who use non-administrator accounts|
|26th Sep, 2010 09:14|
User Since: 12th Feb, 2008
System Score: N/A
Last edited on 26th Sep, 2010 10:26
The typical solution for the need to allow non-administrator users (I run as a non-administrator, and my wife doesn't even have access to perform administrative tasks on her computer - I'm the house admin) to run administrative tasks (such as PSI) is for the program to install a System mode service which uses access control relying on Windows authentication to differentiate which users are permitted to monitor/ command/ control it.
With Microsoft's (long overdue, and very welcome) move to get users to run as non-administrator, PSI needs to move to this or some other comparable model, whereby PSI can be set to start and run as a System task with full privileges in the background, and those users who the system administrator wishes to be permitted to monitor/ command/ control PSI will be given the appropriate access-controlled rights to the PSI service through the PSI user interface.
This would also solve another problem which I've noticed: If a workstation is a Domain member (yes, there are Personal users who have Domains, and, yes, we're weird; continuing...) and the user sometimes elevates to LOCAL\Administrator to run PSI and other times elevates to DOMAIN\Administrator to run PSI, then PSI will have two different databases of scan histories and results. It may even have two different configuration settings, which could get very interesting when considering kernel filter driver load yes/no and order decisions at start-up time. If all of the System / administrative level functions of PSI occurred as a System service, and only user interface configuration items were stored per-user, these problems would all be avoided.
Jay Libove, CISSP, CIPP, CIPP/IT, CISM
|libove||RE: PSI for users who use non-administrator accounts|
|26th Sep, 2010 10:30|
User Since: 12th Feb 2008
System Score: N/A
|A little more detail about why I've encountered the "multiple different administrator profiles" problem where depending on exactly how I run PSI I may get different PSI setings:
I use a neat little tool by Kay Bruns called SuRun (see http://kay-bruns.de/wp/software/surun/ for those who are interested), which is similar to the venerable UNIX "sudo" tool. It allows much finer grained control over when a program runs with administrative privileges without bothering the user with a UAC prompt. For example, if I am logged in, and I execute PSI, then SuRun notices it and automatically, silently, with no prompting for permission or passwords, launches PSI with elevated privileges.
Importantly, SuRun does NOT run the program AS administrator. It runs as my user ID, with elevated privileges.
So I can actually launch PSI on my system THREE ways so that it has all the rights it needs
- RunAs LOCAL\Administrator
- RunAs DOMAIN\Administrator
- SuRun as me with elevated privileges
Each one of these three has its own C:\Users\<someone>\AppData\... entry for the settings.
So, back to the original theory, if PSI maintained its elevated privileges by having a core service running as System, and then arbitrated access requests from (Whatever user with whatever Windows privileges) runs the PSI User Interface based on an access control matrix which, at first, only a real Administrator can control, then the system-related (start at boot, monitor programs, auto-update) settings could be universal and not get messed up / conflict based on which kind of administrator or elevated account happens to be running PSI at any particular moment.
|This user no longer exists||RE: PSI for users who use non-administrator accounts|
|27th Sep, 2010 10:32|
Thank you for your feedback.
The way the Secunia PSI currently runs (requiring administrative privileges) is a reflection of the fact that the PSI accesses restricted resources on your computer, and requires full administrative privileges to scan your entire hard drive.
However, the this "fact" is one of the aspects of the PSI we will be looking into improving in the PSI 2.0 Beta period. Your suggestion is remarkable close to the ideas we are also considering internally.
I will ensure that your feedback reaches the ears of our developers. However, I would suggest that you keep an eye on PSI 2.0 Releases to come.
hope this helps.