LUA

The new version 4 suffers still the old problem: No ability (except some "tricks") to make settings inside a LUA account.

I wonder, what the password option in NOD is good for. On a healthy Windows system there are exact 2 Admin accounts: the predefined one called "Administrator", normally not to be seen or used (only a backup), and the user-defined one, used actually for administrating the machine. That means, there is exact 1 Admin on board. So, why should he set a password, if all users except him cannot do anything in NOD? I never found - or got - the answer.

But a responsible user, who is the admin of the machine, will not use the admin account for daily work. He - or in this case I - have a limited user account (LUA) for that. But without doubt, if I log in as LUA I have not dropped my brain - just in the opposite, I have used it. So there are only bad reasons, that I cannot make settings in NOD from that account. With the already existing password option it would be easily solvable, that no other users can do this.

I hope, that NOD4 will finally will learn, that even a security software has to assist secure computer handling.

 

I believe the password feature was intended, at least in part, to protect NOD from malware being able to modify the settings in NOD without your knowledge or permission.

By not allowing changes to NOD settings from within a limited account, malware is prevented from doing the same - assuming ACLs are configured properly. When running as a limited user, it is probably slightly safer (in terms of malware) to allow changes only from within the admin account, as you reduce the attack surface. (Not that other security software and applications such as SuRun seem to provide access to admin level functions safely enough).

Having said that, I agree with you that companies such as ESET, need to become aware that, more and more, their software will operate on systems with restricted accounts, and need to adjust the user interface (as you suggest) accordingly.

 

Thank you for your opinion, Dogbiscuit. It gives me the option, to make some things clearer.

Your upper quote is a contradiction to the lower one (no offend intended). If the password option does as you describe, it would do this quite obviously also inside a LUA. So this cannot be the point. Further more: On every XP and above you can run apps in the context of an admin, if you know the password. If the password-protection should not be enough, the whole concept of dividing the privileges of admins and LUA would get lost - and in this case it would be totally senseless, if the NOD-settings are "protected".

And more: As I mentioned, there are very uncomfortable "tricks" to change the settings from within LUA. So there is no protection in reality at now. But there is another problem, why many people say "LUA is to complicated for me and has not enough comfort." So NOD motivates the user by the wrong social engineering to do the false = unsafe. And that is bad.

On the other hand, forcing the user to enter the admin account for nothing else then altering a setting does mean, that he has to enter the unsafe shell. Again by social engineering NOD does the opposite, what is expected from a security software. At the same time ESET has the claim for a mostly circumstantial software.

Exact that is the point. Technically the problem appears to be (at least partly), that the settings get written into the HK-LM-branch of the registry. But this would be a solvable problem. The only prerequisite is the willingness, to support safe computer usage.

I mean, it is only hot air, if NOD says (somewhere in the help), that LUA should be used out of security reasons, but prevents the user to use the own software accordingly.

Version 4 is the place to overcome the old mistake.

 

Yes, I suppose it depends on whether you believe the password feature in NOD is as secure (in terms of altering NOD settings) as the restrictions you have when running as a limited user.

 

Any official reaction?

 

Hello,

Thank you for your report.

Regards,

Aryeh Goretsky

 

Thank you for the respond.

I wrote some words about it here, but I expect the day, when we go into content further on here.

 

A lot of programs and also dialogs from Control Panel require an admin password before they can be run. That what User Account Control is for.
Maybe the changes in NOD settings in LUC could be made this way instead of specific NOD password?

 

This sounds, as if you speak about Vista?

The problem is a general one for all Windows versions (since w2k, which is the minimum platform for NOD32).

 

It's quite straightforward. First, enable the option "Require administrator rights (system without UAC support)" in User interface -> Access setup. Then log in to a limited user account and, when attempting to change settings, a prompt window will pop up, asking you to enter administrator credentials.

 

Thank for answering, Marcos. I've found it.

But this feature does not work correctly in all situations, may be a bug:

At first I tried to disable NOD totally from the context menu of the tray icon: I got the question for the user's context and then it worked. Great. Reactivating was easier, as I did not have to re-enter my admin-credentials again. Greater.

Next try: In advanced settings I tried to set the check-mark to an application in the Web-browsers' page. After clicking on OK I git the message "Insufficient permissions to change settings". So no change in this case.

I tried with several other settings (not all), and all that I tried worked following your hint with one more exception: The equivalent setting for email-clients. So they seem to be forgotten for the new routine.


BTW: I came across the page "hidden notification windows". Trying to open the help via question mark there produces only a message box "Failed to launch help". (Probably because this help page does not yet exist?) Where can I read, what this feature does or do you give me the answer, please?

 

We'll check that out and fix it if there's actually a problem elevating permissions when adjusting these settings.

It's likely the relevant help file didn't exist when building the beta version. The dialog contains a list of dialog windows where you ticked the "Do not ask again" checkbox and displays the option that will be selected automatically if you encounter those dialog windows. You can either untick the appropriate option or remove it from the list so that the appropriate dialog is shown.

 

Thanks for the answer.

This leads to another question or bug report:

If I switch in LUA from Standard to Advanced mode and tick the option, to not ask again when toggling, I can do so and I find this in the above said setting window. All this without the need to enter admin credentials. But if I try to remove this setting by unticking I get asked to enter the admin credentials. This makes no sense, as this setting does only affect the said account, not others (as I found by testing). And if I can set the switch to not ask again I also should be able to unset it again inside the same account without the need to know the admin credentials. Even more, as the admin is not even able (in his own account) to see this setting in the setting window, so he cannot do it for the limited user. If the LUA is not his personal own for daily work he will most likely not give his credentials to other persons. This means, there is for the limited user in reality no way back at now.



Finally: Happy Christmas and a successfull New Year to all.

 

I have done that and it worked ok.
However, recently I have noticed that I can change any setting in NOD in LUA without getting prompt for an administrator password.
For testing purposes I have removed a check mark from "User interface> Access setup", logged back into Standard User account and I can still change all the settings without any prompts to enter password.
I have reinstalled NOD and still have the same result.

So it seems that NOD somehow lost it self protection in LUA. Any ideas how to fix it?

My OS is Vista Ultimate

 

Perhaps a Vista-specific bug? Here on XP SP3 it works as it should - besides the above already reported bugs. As soon as I disable the above said option (which can be done in LUA) I cannot do any administrative tasks from LUA, doesn't matter, if I logg off / on.

 

And it did work like that for me since I have read Marcos' post and have changed the settings. However now it has stopped behaving as designed. It might be that something is corrupted in Vista as reinstallation of NOD did not help. I hope Marcos can help with it.

 

Beforehand: The above mentioned problems with Browser and E-Mail settings are solved in RC.

But this one is still left:

As I don't know if this forgotten, I want to pont it out once more:

In a corporate environment it is near to impossible that a normal user (employee) does get the admin's password. But without this he cannot untick the hidden notification window setting. On the other hand the admin cannot do it for him, as this is a user account's setting, only visible for the active account.

Further more there is not the smallest sense, if the user can make a tick in the dialog's box but cannot untick it again.

 

I want to add that I'm running an admin account with UAC enabled. nod32 obviously has full admin access yet the "shield" always appears next to ok buttons, even though it doesn't need it. Is this an intended feature?

 

As I said already, there seems to be a bug and bug report to be overseen.

Without the smallest official reaction I have the fear, that it gets overseen until the final release.

 

Email it betasupport at eset dot sk.

 

I do not see, why I should do this.

Either this is an official ESET forum and ESET uses this forums and it's members for beta testing, than I expect, that Marcos, agoretsky and Co. as ESET Mods do the communication between the company and the forum. In both directions. (Communication is no one-way-road.) Why shall I mail, what they probably have already?

Or this is not the official ESET forum. But in this case I expect, that those words are not written at the title. In this case I also would not have done beta testing and reporting here. (Anyway, 2 of the by me reported bugs in this thread only (not to mentioned the bug reports by others) have been eliminated by them, so it was also ESET, who benefit from this way of communication. But the signs say clearly, that they have overseen the remaining bug - or the communication between the mods and ESET was faulty.)

I do not write to spend my time. An official forum as an official communication platform has for 2 meanings: Official and communication. And this here and not via Mail. Otherwise I do not need a not-so-really-official forum with a misleading title.