Password Protect Avast does not lock everything

[twehrle]

I am currently trialling avast Professional and I have a question about the password protection of access to avast.

I installed the program under my Admin account on W2K. Got it all setup the way I want it. I then set the password for avast. However, when I login under my son's account, which is setup with User rights only, he can still open the interface and change things. His account was able to change the main program settings, screen saver task settings, explorer extension task settings and remove Alerts configurations. I was really expecting all these to be locked as well. Is there some other way of protecting these?

He should be able to perform actual scans, but not be able to change any of these settings.

Indeed, the Resident Protection task settings appear locked, as well as the main interface to the providers running under the Resident Protection. But the above settings should be locked as well.

I did not try to stop any of the providers running under the Resident Protection, with his account. The actions on the menu to stop them, were not grayed out, so I assumed it was possible. I will try that this evening. It should not be possible.

Thanks for any responses.

[Lisandro]

He can still open the interface and change things.

The password blocks the access to the provider settings (protection and virus handling) and common program behavior and settings.
I've tested right now and it worked for a non-administrator accound.

His account was able to change the main program settings, screen saver task settings, explorer extension task settings and remove Alerts configurations. I was really expecting all these to be locked as well. Is there some other way of protecting these?

Seems that your son has administrator rights... this way he can do everything...

I did not try to stop any of the providers running under the Resident Protection, with his account. The actions on the menu to stop them, were not grayed out, so I assumed it was possible. I will try that this evening. It should not be possible.

Tested right now... it worked.
The user cannot change any provider state without the password. The operation is not grayed out but after checking it, the password is asked...

[twehrle]

His account is definitely not administrative. I put him in the Users membership. I even verified this by trying to go to common Windows Control Panel applets (Add/Remove Hardware, Users and Passwords, Automatic Updates, etc.) and Windows responds with a dialog telling him he does not have sufficient rights to open the applet.

Indeed it did block the provider settings. But from the Extended User Interface, I was able to open the common program settings. I was also able to change the Screen Saver task settings and remove an Alerts configuration, along with the other things I highlighted.

This may be a stretch, but I am wondering if this has anything to do with the issue about avast getting installed into the Program Files directory with file security rights that were not restrictive enough.

I guess I will have to look at all this much closer this evening.

[Lisandro]

In fact, reconsidering what you've posted I can see that there is a problem in avast folder permissions that could be directed related to this. If this is the case, it will be fixed in nex avast update.

On other hand, in my installation, things could be good because I'm not using the default path of installation.

[twehrle]

I am going to check those file permissions when I get home this evening.

I have read posts about people correcting those permissions by manually changing the security on the avast install folder (and all subfolders and files) back to inheriting from the parent. Thus everything under the avast install folder reverts back to the "Program Files" directory permissions. For the Users group, this would give him List, Read, & Execute permissions only. Do you have any information related to the success or issues with this manual permissions change?

[Lisandro]

Do you have any information related to the success or issues with this manual permissions change?

No, but I see no reason to not work. Better if you can test if your son could use the antivirus, if the updates are received when he's logged (not only you, the administrator). For me, the permissions are ok and avast worked pretty well with non-administrator accounts.

[twehrle]

He should be able to execute it. I doubt it will update though. At least I am registered for update emails.

Now we are getting into the theoretical why I am trying to do this, instead of the how. The computer I am trying this on first will become his and be installed in his bedroom. He is a natural explorer. He will look at everything and try to tinker with it. I think his curiosity is great, but I have to have some limits to keep my home network protected. I have quite a few things on my home network.

[sidebar]
Also, this is my trial for determining if avast is really up to this kind of robust level of use. If it succeeds, then I am going to purchase Professional licenses and install it on all my machines. This will replace Norton AV 2002. I tried Norton AV 2006, and to put it mildly, it was terrible. I applied for a refund with them. The many reviews I have read about antivirus kept mentioning avast as being good. Almost all the user reviews I read had praise for it. So here I am, trying it out. If I can get past this one issue, I may even reccommend it to my company.

Plus, if it is also installed on my main machine, that I look at every day, then I will know when his machine needs me to login for updates.
[end sidebar]

[igor]

avast! is able to update if a restricted user is logged on; actually, nobody has to be logged on at all and it still should update without any problems.

[Lisandro]

He is a natural explorer. He will look at everything and try to tinker with it.

If he doesn't have Administrator rights... no fear, he can't move back folder security access rights.

Plus, if it is also installed on my main machine, that I look at every day, then I will know when his machine needs me to login for updates.

No need for that, Igor words, final words.

[twehrle]

OK. I have tested this very closely using a plain User account (not Administrator) and here is what I found. I believe I have highlighted some bugs here. For starters, I have version 4.6.763.

The file permissions on the avast directory under "Program Files" was set to inherit from the parent. However, many files and directories underneath this directory had the Everyone permission. I reset all permissions under this directory to inherit from the parent.

I will only highlight the behaviors that were effected by this change.

This did fix the fact that previously the User account was able to change the VRDB settings. Now when an attempt is made to change them, it appears to fail silently. When I look again the setting is still at its previous value. Good.

When Program Settings is selected from the taskbar icons menu, it prompts for a password. This behavior did not change from the previous. However, when the User account selects "Start avast! Antivirus" from this task bar icon and after the user interface starts up, they are able to select "Settings" from the File menu or toolbar, and the Program Settings screen is displayed without any password prompt. I would have thought the same password prompt would have been displayed here also. I did notice though that any changes I made to this screen appeared to NOT be saved. I would press OK and the dialog would close as normal, but when I re-opened it, the settings I changed reverted back to their original state. So good, that they did not save, but the password should have been prompted for first.

On to the big problems.

I WAS able to remove an Alerts configuration from the Alerts folder. This is bad. This effectively stops any notice being sent out, if the particular Alert deleted is one that I have attached to the Resident Protection. I tried restarting the user interface and it was still missing. I was even able to add it back under this User account.

I WAS able to change the properties for both the Explorer Extension and the Screen Saver special tasks. The changed settings persisted after an OK and re-check.

I WAS able to select a System File from the Chest and delete it. As I understand it, these are files that avast copied into the Chest for safe keeping in case something happened. The User account definitely should not have been able to delete them.

Well these are the problems I see with security for avast. I don't know if this is the formal place to document them, or whether there is some bug database I can enter them into. I know that I will need them fixed before I can committ to this product.

Thank You.

[Lisandro]

When Program Settings is selected from the taskbar icons menu, it prompts for a password. This behavior did not change from the previous. However, when the User account selects "Start avast! Antivirus" from this task bar icon and after the user interface starts up, they are able to select "Settings" from the File menu or toolbar, and the Program Settings screen is displayed without any password prompt. I would have thought the same password prompt would have been displayed here also.

Bug 

I did notice though that any changes I made to this screen appeared to NOT be saved. I would press OK and the dialog would close as normal, but when I re-opened it, the settings I changed reverted back to their original state. So good, that they did not save, but the password should have been prompted for first.

Fully agree.

I WAS able to remove an Alerts configuration from the Alerts folder. This is bad. This effectively stops any notice being sent out, if the particular Alert deleted is one that I have attached to the Resident Protection. I tried restarting the user interface and it was still missing. I was even able to add it back under this User account.

Are you referring to Home version alerts or, on contrary, Professional version?

I WAS able to change the properties for both the Explorer Extension and the Screen Saver special tasks. The changed settings persisted after an OK and re-check.

Bug 

I WAS able to select a System File from the Chest and delete it. As I understand it, these are files that avast copied into the Chest for safe keeping in case something happened. The User account definitely should not have been able to delete them.

Fully agree.

I don't know if this is the formal place to document them, or whether there is some bug database I can enter them into.

You're on the right place.

[twehrle]

Are you referring to Home version alerts or, on contrary, Professional version?

This is the Professional version I am testing. I removed the Alert configuration using the Enhanced User Interface. I do not use any skins for the user interface. Again, I removed this Alert configuration under a User membership account.

[igor]

Well... this password feature was always meant to protect the settings of the resident protection - not the other options. So, you may call it a bug, but this is actually how it was meant to be.

I'm not saying it wouldn't be wise to reconsider the behavior... and possibly prevent entering the settings completely without the password. That, on the other hand, may be too restrictive for some users.

[twehrle]

I assume, Igor, that you are a developer on the project? I am sorry to hear you take this approach to the issue. You see, I am a software developer as well. Been doing this for over 15 years, specializing in Java and user interfaces for 11 of those years.

With the way the avast interface is designed, setting the password from the programs main, and initial interface (the taskbar menu), it is natural for a user to expect that this password protects the entire program. If you had wanted it to affect the Resident Protection only, then it would have been more natural to put the password setting function within the Resident Protection settings. One of the first rules of good interface design, is that the interface should behave consistently and as naturally as expected.
http://www.joelonsoftware.com/items/2006/03/07.html

The other aspect of this is, that is has been expected ever since Windows had membership profiles, that access became more restrictive as you went from Adminstrators to Power Users to Users. This is generally expected by any software package that runs on Windows. To violate this, severally limits the scope of users that can use your product.

I do really applaud what you guys are trying to do, by competing with the big guys (Norton, McAfee, etc.) in a product category that many people need. Many of your features are better than what these guys provide. However, this issue really does appear to be either a bug or just flawed design. If you push back on the issue either because you don't want to be told you have a bug or don't want to admit your design is flawed, then that tells me a lot about where you product is going in the future.

Thanks for your time.

[CharleyO]

***

Well, I really do not think Igor meant what he said as to "push back" against your statements. In fact, I read what he posted as saying there is a possibility for change. He just simply includes that while the change might be a wise thing, it could also be too restrictive in some cases.

Twerhrle, you have made some valid and logical (to me) assessments which I feel sure concideration will be given to in the future by the Avast team. That does not mean the changes will happen but ... give them a chance.


***