Require UAC prompt to Install add-ons to installed NVDA copy: Install to Program Files, not AppData #16235
Comments
seanbudd
added
blocked/needs-product-decision
|
Hi, While I understand the security implications for moving add-on data to program files (with or without "x86" suffix), I think this is quite an overkill. More importantly, the proposed change does not align with portable NVDA where add-ons are used by users for various reasons, or when wishing to make a portable backup of NVDA installation which includes add-ons for currently logged on user. Also, add-on authors must declare that their add-ons are secure and are trustworthy, including not abusing admin privileges because just saying "yes" to UAC does not fully guarantee that Python/C code are secure (UAC communicates two things: the code about to be executed is trustworthy, and users really know what they are doing). In summary, relying on UAC and its messaging/experience may provide appearance of asking for trust, but it does not fully guarantee what the add-on does is what it claims to do (for that, I think source code audit of add-ons is more effective). Thanks. |
Maybe this title is misleading. The idea here is installing add-ons to the install directory, not the config directory. For portable copies, these are more or less the same (userConfig in the portable copy directory).
We don't have the capacity to meaningfully declare add-ons as secure or trustworthy. What we can do is ensure users understand these risks clearly and only users with permission to install software can take these risks. I disagree here with your understanding of the purpose of UAC prompts. Users most often run into this prompt when installing software. For most users it is about trusting the source of the software and being willing to let it modify your system. I am not sure to what extent users trust the code itself just because it requires administrator approval to install it. |
|
I agree with @seanbudd. This will definitely increase the trust in NVDA in corporate environments. |
|
@Adriani90 - we try to include all that information here: https://www.nvaccess.org/corporate-government/ |
seanbudd
changed the title
|
about trusting the source of the software and being willing to let it modify your system. I am not sure to what extent users trust the code itself just
because it requires administrator approval to install it.
You perform the same UAC operation on installing unsafe packages, trust in the code itself is independent of the safety process around restricting
installation. At the UAC installation prompt is where the admin/trusted user decides "I trust this software installation to let it modify my machine".
But doesn't that make the problem worse, not better? Now, instead of installing
a potentially unsafe add-on in a non-admin account, I must install it in an
account with--or that can get--admin privs.
Therefore an add-on that was only installed in one, potentially non-privileged
account before, must now be installed for all accounts, system wide.
I think this also means that we must remove the scratchpad feature. Else any
add-on could be installed there, circumventing this supposedly more secure
add-on paradigm.
Lastly, doesn't this just contribute to "UAC autonomy"? I was just watching a
video today, from a former high level Microsoft developer, complaining that apps
and installers are requesting admin access for operations that don't, and
shouldn't, require it, just because they don't know any better way.
He pointed out that this is leading to users developing an automatic approval
mentality for UAC requests, that is diluting their intended function.
I predict this is going to lead to a thought process of "just agree, that's
something they make you do for add-ons now", not the effect that you are
expecting it to have.
|
Add-ons are inherently capable of performing privileged actions even from non-privileged accounts. There is a pending advisory related to this, but this is also documented in the user guide and corporate page. As such, this change doesn't really affect the range of risk, but more accurately reflects it.
This could also be moved to program files? I guess the other concern is the python console also has the same risks as scratchpad and add-ons, and that is included by default. I disagree with the UAC autonomy note, as I believe this is a clear example of when UAC should be used, i.e. when installing code that can run at system level. |
Are you completely sure? I am on a corporate environment with quite strict security policies, I cannot update or install anything and every UAC promt requires admin priviledges to be accepted. @seanbudd |
|
@seanbudd I think there are some statements in your proposal that are not true, at least not necessarily.
If I'm running NVDA as a standard Windows user (not administrator), apart from UI Access, the add-on has no more permissions than every other application running either portable or installed on a per user basis (see below).
I think this is also incorrect. With the Windows Store, Microsoft is following a pattern in which applications are installed on a user basis (see %localappdata%\Microsoft\WindowsApps). In my opinion, NVDA has no duty to avoid running malicious code, that's up to the system. Instead, it should avoid installing it. The patterns that Microsoft follows are also much more meaningful in that case. I can think of:
|
As mentioned in the proposal, add-ons would continue to have a separate configuration folder with NVDA config, e.g. in AppData.
No - this is not in any way a change how add-ons are perceived security wise. As mentioned all over NVDA, add-ons are not secure or tested and you must trust the author if you wish to install one. The idea here is to highlight that you are essentially installing a new independent and unverified program every time you install an add-on. |
As mentioned earlier, add-ons can run at whatever level NVDA is running, including as administrator. i.e. when performing an update or running the com reg fixing tool add-ons can hijack UAC elevated privileges.
https://www.nvaccess.org/files/nvda/releases/2024.1beta10/documentation/userGuide.html#SecureMode |
This would be a false sense of security. There is no security difference between add-ons from outside of the add-on store and add-on store add-ons.
I think implementation of this and adoption of this from add-on authors would be more challenging, but this is certainly an alternative proposal. |
I think a difference with this case is these applications are not being run from Program Files, I think the explicit issue is we take code from AppData and execute it from Program Files. |
|
@seanbudd Perhaps an intermediate proposal may be considered?: Create a new "mode" in NVDA, called "corporate mode" or "Restricted Mode" or some other appropriate name.
It would be a trivial matter, to create two installers for every release: one that contains this file, called the "Restricted Corporate Mode Installer", and the usual installer that we generate now.
This lets us separate the user groups by their perceived needs, at little inconvenience to either NV Access or the disinterested portion of the user base. |
|
This proposal really bothers me, the fact that an addon would be installed globally. So another user who can perform an admin right may inject an unknown addon into my screen reader which I treat as a very sensitive app as it is capable of gathering keypresses and thus passwords, etc. Would I get a notification when I start NVDA that another user has installed an addon and would I have any chance of disabling it before any of its code could run as my user? I personally would see this as a degrading of security. |
|
Actually yeah we really should think more about some alternatives here and I find @mwhapples point about user specific add-on installation very valid. It didn't came to my head before. :-)
|
|
I think @mwhapples is right to point this out. I was assuming, but I shouldn't
have, that if any version of this idea was implemented, any add-on globally
installed like this MUST be disabled automatically by default, for all but the
installing user.
|
|
I am not really convinced this is a good solution. Corporate specific requirements can be easily implemented via admin features such as command
line parameters or so.
Some can. But if we eventually expand this to disabling NVDA features more
granularly, or introduce some kind of management interface for global options,
they will need a config file anyway. My suggestion provides one.
Moreover, your proposal would really bring the maintenance effort to a next level and I think this is an overkill.
I am most interested in hearing an explanation of that statement.
In my proposal, NV Access must create and manage one single additional file.
At least at first, the code needed to make it work is minimal--does the file
exist in the proper place? If it does, set a flag on globalVars. Further
"disable if in corporate mode" checks may be done with block actions, which
@seanbudd already wrote a couple years ago.
The most maintenance is the code for the specific proposal under discussion, for
installing add-ons in a global context instead of a user context; and that will
be written anyway if this proposal goes through.
Please elaborate the maintenance overhead I am missing in my suggestion.
|
|
Hello, |
|
Hi, I think this would be the moment to use Group Policy (finaly). That way enterprise admins can toggle features on and off at the individual or corporate level, including allowing add-on installation and enablement. Thanks.
|
Add-ons can indeed request NVDA to elevate, in fact that's what I do in RDAccess. However, I'm pretty sure that an add-on can't elevate if the UAC screen is enabled and a user is prompted. In that stage, it became the responsibility of the user.
NVDA is certainly not unique in this. In fact, this applies to every application that supports some form of user extensions. I am thinking of applications such as Foobar2000, visual studio code (system wide install), global installations of Python. And how about other screen readers, like JAWS?
In that case, I'd rather see add-on store add-ons made more secure. I understand that there is a security risk associated with using add-ons, but I'm afraid I cannot support such a drastic change as proposed in this issue. @mwhapples also has a very important point. |
|
I tend to agree with people who think that add-ons shouldn't be installed globally but for specific users.
This is true, but imo we shouldn't give the feeling that the store has no difference respect external sources, since this would be also a false feeling. NVDA checks sha-256 to check add-ons integrity, and submitting add-ons to the store has requirements that ensure that add-ons are not released as stable for experimental API versions. this is not trivial, so it's not the same to use the store that external sources. |
|
I fully agree with @LeonarddeR and @mwhapples that moving add-ons to program files is not an acceptable solution at all. What @LeonarddeR pointed out about other programs which support extensions is also very true. The difference, of course, is that many of these(JAWS being a prime example) have a proper API boundaries between extensions and the main software, and that should be the direction NVDA moves in.
How exactly should this be implemented? For me this appears pretty impossible to do. As a middle ground: has it been considered to leave the install location alone and just show UAC screen during add-on installation? This ensures that non admin users cannot install add-ons, yet very little changes other than the additional elevation requirement. I'm not sure how annoying that would be for users though. The truth of the matter is that NVDA is not really usable without add-ons, so if their installation is going to be made any more difficult than it is now, we really need a mindset change where add-ons are required only for the most unusual usages, and most of those which are used commonly are integrated into the main product. |
|
Many valid points have already been raised in this thread. I also don't like the idea to putting all addons in a privileged location by default and fully restrict users from installing addons in non-admin environments. If we go that way, I would like to see a clear policy of what we could and should put in core and why, since some addons provide very useful functionality without accessing any resources outside NVDA. Why are some rarely used appmodules in NVDA for example and does NVDA not provide sensible defaults for some other applications and a feature to keep Bluetooth and bad behaving sound cards open? Especially the latter is clearly needed on many machines and is in JAWS for a few years now. I have seen NVDA in some corporate environments and I think these customers would be better off with:
I would love to hear from more NVDA users in a corporate environment. |
This reached now also last NVDA alpha version, so no addon needed for that anymore. It took years to come though. Reading this very interesting conversation, I think we should really challenge the aspects why so many addons are needed at all. It still contradicts the goal of better accessibility when we start restricting their functionality and though better security is needed. Especially NV Access did never totally deny a functionality proposed for the core if the community was insisting on having it in the core. However, NV Access developers and also contributors challenge these proposals and exchange arguments in a healthy way. Some add-on authors might feel overwelmed by the standards they have to comply with in terms of coding etc. But still this is needed and in the end it is the best security check you can have. |
|
I think also @nvdaes brings also a very valid point. We can work on the add-ons security checks to improve them first before moving totally their installation into system admin's hands who very often do not understand accessibility needs because they are too far away from the community. |
For this proposal to work properly system amins will have to really digg deep into NVDA's functionality and its add-on environment. At least from my experience, all system admins I ever know in usual companies have very very basic NVDA knowledge. Letting them the decision of what users might need as add-ons to be preinstalled is not really going to work.
I am working in a development financing institution with very strict security policies, and this approach would probably be the most atractive one for them. However, they still allow me to install add-ons but I have to send a request for that, otherwise they look at every NVDA update if there is an unknown add-on and remove it from my user account. |
This requires a very advanced knowledge about the software you apply policies on. I doubt admins will look that deeply into it if there is only a very small amount of people using this software in the company. They will rather block as much as possible to minimize risks and people would have to ask everytime for the release of a specific configuration / setting and explain why it is useful. |
|
I think, like many people in this discussion, that the problem would rather be how to strengthen the security of add-ons rather than moving them from their directory. I do not know how the add-ons were checked before the release of the add-on store, but if there had to be a manual code check of each add-on, a lot of evaluators would need to be put in place for the publishing and updating of add-ons to happen quickly. I also think that in manual control, the evaluator should not decide whether the add-on should be published or not based on its usefulness, but only on its security, contrary to what has happened with add-ons published on the old store that were refused because they were deemed useless. I also think that already, to improve the security of add-ons, there should be a stricter way of authenticating oneself as an author so that NVAccess can have reliable author coordinates (name, first name, email address) and not use Github as it is now, where anyone can submit an add-on for someone else and where it is very easy to change one's name or delete information afterwards. Finally, as @nvdaes and @XLTechie said, we should focus on the security of add-ons rather than disturbing the user with many warnings. |
But add-ons review is a process made by volunteers, and to check security time is required, so it's understandable that reviewers don't want to waste time in reviewing add-ons not considered useful.
Currently just 6 persons are considered trusted submitters, i.e., just they can submit add-ons on behalf of other authors. Other submitters need to be approved, and some evidence, like the GitHub URL, is checked to see if the submitter is the owner, of if he or she has permission from the add-on authors to submit it to the store. |
|
Would not be a good way to restrict the human review process only to security related aspects? All other aspects of the old review process are not relevant for the human review process or can be done via the discussions later on if needed.We just have to make sure that reviewers are experienced in security related questions.Then NV Access can make a certification process for a reviewer.As soon as the addon is reviewed from a security perspective, it is flagged as secure in the addon store. Then we could finance reviewers by donations from the community. They would have to attach a security note to the addon they reviewed.Von meinem iPhone gesendetAm 29.02.2024 um 12:48 schrieb Nael Sayegh ***@***.***>:
I think, like many people in this discussion, that the problem would rather be how to strengthen the security of add-ons rather than moving them from their directory. I do not know how the add-ons were checked before the release of the add-on store, but if there had to be a manual code check of each add-on, a lot of evaluators would need to be put in place for the publishing and updating of add-ons to happen quickly.
I also think that in manual control, the evaluator should not decide whether the add-on should be published or not based on its usefulness, but only on its security, contrary to what has happened with add-ons published on the old store that were refused because they were deemed useless.
I also think that already, to improve the security of add-ons, there should be a stricter way of authenticating oneself as an author so that NVAccess can have reliable author coordinates (name, first name, email address) and not use Github as it is now, where anyone can submit an add-on for someone else and where it is very easy to change one's name or delete information afterwards.
Finally, as @nvdaes and @XLTechie said, we should focus on the security of add-ons rather than disturbing the user with many warnings.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
Re: usefullness and review, I think if people get a reward for it (i.e. through donations), there are certainly enough people who would be willing to do it even if the addon is not useful. We just have to find a bunch of people who are really trusted by the community and reward them to do it.Von meinem iPhone gesendetAm 29.02.2024 um 12:56 schrieb Noelia Ruiz Martínez ***@***.***>:
I also think that in manual control, the evaluator should not decide whether the add-on should be published or not based on its usefulness, but only on its security, contrary to what has happened with add-ons published on the old store that were refused because they were deemed useless.
But add-ons review is a process made by volunteers, and to check security time is required, so it's understandable that reviewers don't want to waste time in reviewing add-ons not considered useful.
I also think that already, to improve the security of add-ons, there should be a stricter way of authenticating oneself as an author so that NVAccess can have reliable author coordinates (name, first name, email address) and not use Github as it is now, where anyone can submit an add-on for someone else and where it is very easy to change one's name or delete information afterwards.
Currently just 6 persons are considered trusted submitters, i.e., just they can submit add-ons on behalf of other authors. Other submitters need to be approved, and some evidence, like the GitHub URL, is checked to see if the submitter is the owner, of if he or she has permission from the add-on authors to submit it to the store.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
I don't think that rewards have a lot of impact in finding reviewers, and this would bring the problem of donating to people instead of doing it directly to NV Access for NVDA, like it's already done for other projects. Also, reviewers may not be very active, and this should be measured in some way. some kind of certification maybe required, and I don't know if NV Access can do it given other priorities. |
|
My definition of useful in the context of this thread is what reviewers consider that can be enough useful to dedicate time and efforz to review add-ons. |
That still isn't really a full definition if "useful" is a criteria which can determine if an addon will be reviewed. Is it a reviewers ability to decide whether they feel it is useful based on their own view of what constitutes useful, is there standard criteria to determine useful which the reviewer must use regardless of their own personal opinion, could an addon author appeal a decision that their addon is not useful, etc. |
|
Usefullness is not and should never be part of the add-on review process. Usefullness is subjective and should be at the reviewer‘s freedom to decide if he or she wants to do the job or not. If an add-on is useful for a reviewer or from its point of view for the community, then this might increase the motivation for doing this job. So let‘s stick to the security aspects which this discussion is all about. Von meinem iPhone gesendetAm 29.02.2024 um 14:57 schrieb mwhapples ***@***.***>:
And define "useful",
My definition of useful in the context of this thread is what reviewers consider that can be enough useful to dedicate time and efforz to review add-ons. For example, I didn't consider useful to review add-ons consisting on adding functions that can be done from NVDA itself, just changing shortcuts, in short.
That still isn't really a full definition if "useful" is a criteria which can determine if an addon will be reviewed. Is it a reviewers ability to decide whether they feel it is useful based on their own view of what constitutes useful, is there standard criteria to determine useful which the reviewer must use regardless of their own personal opinion, could an addon author appeal a decision that their addon is not useful, etc.
If reviews to treat an addon preferably were introduced, then the process to get that privileged status needs to be clear and applied consistently.
My point about a clear and consistently applied process extends beyond "useful", there may be other criteria for certain standards (eg. would NVAccess want to be seen giving a seal of approval to an addon which may have embedded political messages, etc). Getting the definitions correct for the criteria though would be important. One may even say "security" needs defining, security of what and for whom (eg. is it simply protecting the system from code which may damage it or does it extend to protecting data privacy and code which may only gather data but lets the system function normally).
I admit a bit of a minefield and quite understandable if NVAccess decided not to go there leaving it for the user to determine whether it meets their own criteria for there own needs and priorities. That makes me think another reason why if reviews were done for the need for a clear and consistent process, so the user can assess whether the review even deals with their concerns and needs.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
While it is very likely the discussions about improving add-ons security should be done somewhere else, until it is not I'll post some thoughts in this issue. Code reviews were pretty useful nevertheless, as they ensured that most pretty badly programmed add-ons, or one whose behavior was totally un-intuitive weren't available via the official sources. |
|
Does anyone know how other types of apps become trusted? I mean if someone downloads an app / or a browser extension in the app store, or in the Microsoft store or chrome web store, how do users or corporates make sure they can trust them? At least I could find some useful information.
I would say the first 3 points can be quite easily covered in a review without much effort, with a bit of technical knowledge. For mobile apps and browser extenstions at least, there are some tools where you can throw the code in and they generate a security report. In general it seems following behavior should people have before installing extensions of any kind. This could be rewritten as indications in the user guide and on the corporate environment website: |
|
So in summary from my point of view following could be done to improve the security perception:
|
|
I found a very interesting article on how to build github CI workflows / actions with codeqL and Bandit to analyse python repositories automatically as far as possible. Here is also an example repo with already built in actions to see how it works: I attach the article as a word document, it comes from here: |
|
Just words in support of people who are against this issue. |
|
I created discussion #16241 I am closing this issue due to lack of support from the community. Further ideas can be discussed in the new discussion. |
|
Hi, I don't think so - if NV Access opened it, surely there could be a reason for it. Just because the community does not support it should not be the reason for closing it unless the original poster (NV Access) agrees with community assessment. Reopening. Thanks. |
I support Joseph action and arguments here. |
|
If someone creates and issue (even being nV Access,) then it seeks community feedback and advice. If the support is not given on the basis of the arguments in the description or further conversation comments, issues and requests are closed, no matter who creates them. This is the triage policy and the practice we have for years. We cannot put anyone into advantage because it has a certain role. I hope we don't create a community with unhealthy hierarchies. So in case @seanbudd has further arguments which contribute to support his statement in the description we can reopen the discussion and the community feedback loop. Otherwise there is already an alternative discussion where ideas can be further discussed. |
|
I didn't know the mentioned practice about triage, @Adriani90 . Sorry for my quick reply without knowing this. |
|
Hi, When an NV Access staff (or for that matter, members of any organization) posts something, they are speaking on behalf of both themselves and the organization they are part of. Because Sean said there is a pending advisory (see his initial comment), it can be inferred that NV Access staff had an internal discussion about it. I would say this also applies to the wider community - when we comment, we would think about individual and other roles and groups/organizations we are a part of. The community could close an issue if we haven't heard from original posters for a while, and lack of communication is a strong justification which can both encourage and discourage participation (encouraging folks to answer questions in a timely manner, discouraging because issues might be closed just because we did not hear from people). But if we are dealing with a potential and incoming security advisory on a topic with community-wide consequences, and if the organization responsible for representing product development is deeply interested in this topic, then I think organizational members should be given a chance to respond rather than closing an issue outright due to community opposition. This last sentence is where I'm getting at and I strongly disagree with closing this issue. Besides, several people have offered other justifications and thoughts after Sean posted his responses, and I think it would be better to let Sean and other NV Access staff offer their thoughts to subsequent comments. What I'm offering is a pircutre of a higherarcy, but that of negotiations and dialogue. Thanks. |
@lukaszgo1 I really don't think NVDA should move in that direction. The main thing that makes NVDA addons superior to scripting engines of other screen readers in my opinion is exactly that add-ons can do more or less anything. I think it is ok if NVDA gets a version or mode spesificly designed for secure environments, and it is implemented there, but I don't think add-ons should be restricted in any way in what they can do in the normal version/mode. From NVDA's product vision document
|
|
@XLTechie I noticed that, and corrected the comment. I somehow managed to put your name there instead of @lukaszgo1. Sorry for that |
|
Sorry @Emil-18, I missed that update. I will delete my comment, and eventually
this one.
|
|
Thanks for the earlier discussion. |
Is your feature request related to a problem? Please describe.
Add-ons are currently installed to AppData, a user specific folder generally used for holding app configuration and data.
Add-ons are executable code, that runs at a system level.
Windows is designed to protect the system from installation of dangerous code through using the Write protected folders for Program Files.
Code that must run at a system level is generally installed to program files, and protected by UAC administrator approval for installation.
A commonly raised security concern is that NVDA users can install malicious add-ons, meaning that a malicious or naïve user can wreak havoc on their system.
Secure mode prevents the installation or modification of add-ons, however in many environments secure mode is overkill.
By installing add-ons to Program Files, and requiring admin approval for each install, we are following the common Windows patterns associated with installing potentially dangerous software.
By performing the UAC approval on a per add-on basis, users may better understand the risk involved, and approach with the same caution that they would when installing any software with a UAC prompt.
Describe the solution you'd like
Installing add-ons to program files would ensure that administrator approval is required for the installation of any add-on.
It would have the side affect of installing add-ons for all users of a machine, so different users of the same machine would have to disable/enable desired installed add-ons on their own profile.
Add-on authors would probably have to be conscious of the change, differentiating between the add-on installation folder, and the add-on individual user config folder.
As such, this is probably an API breaking change.
For portable copies, this won't be a significant change, as the config directory is stored within the portable copy and portable copies are can be inherently packaged with arbitrary insecure code.
Describe alternatives you've considered
The current warning system conveys appropriate risk, and administrators are able to prevent modification/installation of add-ons with secure mode.
As such, this change is not of a large material benefit.
This proposal just aims to align the process with a common UX for windows.
Additional context
Other extension libraries generally don't require a UAC prompt to install an add-on, but these extension systems generally aren't as risky as NVDA, and are safely sandboxed.
The text was updated successfully, but these errors were encountered: