Prevx Settings - Non Administrative?

Discussion in 'Prevx Releases' started by STV0726, Oct 9, 2010.

Thread Status:
Not open for further replies.
  1. STV0726

    STV0726 Registered Member

    Joined:
    Jul 29, 2010
    Posts:
    900
    Prevx has to be protected by a password, because the settings are considered changable without needing admin rights.

    Why is it designed like that? To me that seems insecure. Prevx should have an option to only allow admins to change settings.
     
  2. Triple Helix

    Triple Helix Webroot Product Advisor

    Joined:
    Nov 20, 2004
    Posts:
    12,013
    Location:
    Ontario, Canada
    You can password protect via Basic Configuration!

    HTH,

    TH
     

    Attached Files:

  3. Tarnak

    Tarnak Registered Member

    Joined:
    Feb 5, 2007
    Posts:
    3,877
    TH, we have nearly the same, but not quite...:D
     

    Attached Files:

  4. STV0726

    STV0726 Registered Member

    Joined:
    Jul 29, 2010
    Posts:
    900
    Password protection is good and all but I don't understand why the settings aren't administrative.
     
  5. PrevxHelp

    PrevxHelp Former Prevx Moderator

    Joined:
    Sep 14, 2008
    Posts:
    8,242
    Location:
    USA/UK
    It's just for improved ease-of-use for the administrator. We encourage users to run as a limited user and in doing so we don't want to make their lives harder if they're making a simple configuration change. Password protection is recommended if the user has other users on their PC which aren't trusted and our Enterprise product automatically hides all configuration options and only allows configuration from the central console.
     
  6. STV0726

    STV0726 Registered Member

    Joined:
    Jul 29, 2010
    Posts:
    900
    The way Prevx configuration works currently is fine, because as you said, if one wants to protect configuration from other users they can use password protection. I understand now why Prevx takes that approach, because many people will already feel hassled enough that they have to use a LUA/SUA, and adding one more step might cause them more aggravation.

    I was just comparing it to, for example, Sandboxie, which is another program popularly discussed here and used by security experts. Sandboxie in the "Lock Configuration" dialogue lets you set a password, but additionally, you can chose to have settings be administrative or not administrative. So you don't even need to set a password locally in Sandboxie if your admin account on Windows has a password.

    The convention I use is, I don't put a password locally on a program if UAC will protect it naturally.
     
  7. dabruro

    dabruro Registered Member

    Joined:
    Aug 23, 2006
    Posts:
    15
    Location:
    New York, US
    I don't see how it's sufficiently secure to allow any and all non-adminstrator limited users to change the settings so long as they enter a password. If this limited user account is infected and "pwned" by malware, the malware or remote controlling badguy could easily (a) steal the password, or (b) simply insert mouseclicks or keystrokes to change the settings after the user has entered the password.

    The whole idea of a limited user account is to protect the rest of the computer even if that account is compromised. To me it makes no sense that there's a "Maximum Self-Protection" setting when there is no protection against a limited user once someone has entered a password in that insecure account.

    If you were to require escalation to an admin account (Vista / Win7 at least), at least Windows would protect the admin password by isolating the password dialog (represented visually by graying the rest of the screen). I think it does even more than that to isolate the escalated process but I'm not an expert.

    Also, I don't *want* to have yet another password for Prevx. Why not just escalate and have us enter the admin password, like for example Microsoft Security Essentials does?

    Or *at least* give us the *option* of preventing changes by a limited user.
     
Thread Status:
Not open for further replies.