When a user installs my application how do I keep User Account Control from producing this dialog? And no I don't want to tell them to disable UAC.
(source: netron.com)
You'd need to design your installation such that it doesn't require administrative access to install, which essentially means that you'll need to install inside the user's home directory instead of ProgramFilesDir and write registry entries only to HKEY_CURRENT_USER. For more details on how do this with a .MSI package, see this article. Inno Setup also has some details on limited user installs.
I don't think Visual Studio's setup project builder is capable of producing packages that don't require administrator rights to install. In any case, Vista seems to assume that anything that looks like a Setup.exe needs elevation (and results in the prompt).
Code signing will not remove the prompt, it will only make it say "Program XYZ from Developer Name wants access to your computer" instead of "An unknown program wants access to your computer".
You need a code signing digital certificate from a certificate authority like Comodo or VeriSign. It's debatable how useful it is, though, because it only replaces this scary-looking warning with a slightly less scary warning (yellow alert vs red alert) that says "Publisher: " instead of "Unidentified Publisher" and still tells the user only to run it if they trust you.
I'm somewhat doubtful that the average user really notices the difference between the two warnings.
Your application would need to be certified by microsoft.
User Account Control, as it says at the bottom of the dialog, but you don't want to do. No other way. Either that or get it signed/certified? :)
Related
I am working on a windows application. After creating the installer file i.e. MSI, it gets installed and works perfectly however, once i upload it on cloud server and try downloading it from there and install it, i get the warning message saying "Microsoft Defender Smart Screen Prevented an unrecognized app from starting. Running this app might put your PC at risk" (below screen).
Any help would be greatly appreciated!!!
You can just submit your software to Microsoft for malware analysis
https://www.microsoft.com/en-us/wdsi/filesubmission
Basically they scan the file, and establish reputation. It works even with Self-Signed Code certificates.
I have linked to an answer above. Might summarize quickly:
Digital Signature: You need an EV-Certificate to sign your setup to gain "trust outright" (Interesting concept?).
False Positive Check: Run your binary through false-positive detection by checking with multiple anti-virus software. This site is a great help: https://www.virustotal.com. Another one you can try is: https://opentip.kaspersky.com/ (Threat Intelligence Portal). For further resources, search for "malware" here: https://www.installdude.com/jumpgate.php
Flagged Downloaded File: You might also want to make sure the file is not flagged as downloaded from another computer:
Description of this file tagging feature here (point 2)
"This file is blocked because it came from another computer"
Please check the linked answer for more details (don't want to create too many similar answers - "dual source problem" - hard to keep updated): How to add publisher in Installshield 2018.
Through WiX installer I installed my Windows application and folder is being created under c:\ProgramFiles with .exe and required dll's.
While running the .exe I am getting the System.UnauthorizedAccessException.
Please let me know if there any helpful suggestions.
Please find the below event log for reference.
Application: xxxxxxx.exe
Framework Version: v1.0.0
Description: The process was terminated due to an unhandled exception.
Exception Info: System.UnauthorizedAccessException
at System.IO.__Error.WinIOError(Int32, System.String)
at System.IO.FileStream.Init(System.String, System.IO.FileMode, System.IO.FileAccess, Int32, Boolean, System.IO.FileShare, Int32, System.IO.FileOptions, SECURITY_ATTRIBUTES, System.String, Boolean, Boolean, Boolean)
at System.IO.FileStream..ctor(System.String, System.IO.FileMode, System.IO.FileAccess, System.IO.FileShare, Int32, System.IO.FileOptions, System.String, Boolean, Boolean, Boolean)
at System.IO.StreamWriter.CreateFile(System.String, Boolean, Boolean)
at System.IO.StreamWriter..ctor(System.String, Boolean, System.Text.Encoding, Int32, Boolean)
at System.IO.StreamWriter..ctor(System.String, Boolean)
at System.IO.File.AppendText(System.String)
Don't try to write where applications should not write. Use other folders like for example:
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
If there is no possible alternative, which I seriously doubt, run the executable with administrative privileges.
https://msdn.microsoft.com/en-us/library/bb756929.aspx
Cross-Reference: A related issue is how to store settings for applications overall. Where to put the files or settings:
Create folder and file on Current user profile, from Admin Profile
Cause
This looks like a simple access violation - you try to obtain write access to a file which you do not have permissions for - in the context you are running (files under %ProgramFiles% are not writeable for regular users, or non-elevated admins - barring file virtualization, see section 9 below).
Here is a generic launch error check-list - probably not useful since you basically have a simple access violation (so it seems). Not sure why the linked answer has been downvoted though. I might have messed up a couple of points - it is just a messy list meant to spark some ideas. Including here for easy retrieval.
Suggested Possible Fixes
Here is a list of a few possible approaches you can use to either work around the problem, fix the cause of the problem, or redesign things
so the problem is effectively avoided. And there are a few approaches
that are merely possible and rarely used. I would frankly consider
approach 10 - HKCU registry keys for settings - combined with a cloud approach for retrieval or copy from a read-only settings file.
The below list is not in order of preference. In fact, approach number 1 is very undesirable in my view. Approach 6 can be effective, but not that great (certainly better than 1 though). I can live with the other approaches (except 9), and 2 is probably the most common to use.
1. Elevate Application (Admin Rights): As others have suggested you can run your application with admin rights (very bad practice these days - admin rights are pervasive, the keys to the city, and make your application a hacker target and also makes the application more dangerous if it contains bugs of caliber). Here is a short how-to: How do I force my .NET application to run as administrator?.
Admin Users Only: Crucially, elevation will not work for normal users! (they will be prompted for an admin password). Only admins can elevate!
Blank Admin Password: If there is a blank admin password on the box (common on home PCs), any user can elevate any binary set to elevate to admin rights at will (using the blank password account) - whilst logged into their own restricted account (they can obviously also already log in as admin with the blank password account and launch absolutely anything - so the security hole is already there with the blank password regardless of elevation issues - but why allow elevation with blank password accounts?).
UAC: What happens when UAC is disabled? Standard users are probably just not prompted for a password, and the launch fails? I haven't had the chance to try yet.
Security: In certain scenarios elevated processes appear to be able to launch other elevated processes that can outlast the original process (depends on launching user's NT privileges). Madness.
2. User Profile (Move File): You can determine what file is causing the access violation (some sort of settings file?) and move it
to a location where users have regular access rights in all cases.
Generally somewhere in the user profile (recommended).
3. Read-Only Access: Very often you can get away with read-only access for settings files. Perhaps you can enforce this approach
instead? It all depends on your application's design. Perhaps you can
handle the access denied exception and then run read-only?
4. Internal Defaults: As a flavor of the read-only approach, you can lose the whole settings file and rely on internal defaults. Rarely
an option I think, but possible. Might be good if you actively want to
hide the settings? You just compile a new binary for users?
5. Online / Clouded Settings?: Some people like to eliminate settings files altogether (or make them read-only) and then retrieve
the "real settings" from a database on launch. This approach can have
dramatic advantages - especially for corporate applications - settings
managemenent and versioning, elimination of user profile roaming
issues, etc... (and challenges of course - network issues,
firewall, proxy, etc...).
6. ACL Permissioning: You can apply ACL permissions to the file in question on installation, allowing regular users to write to it. Not great design at all, but it will work. And certainly better than running with admin rights (elevated) - because you pin-point the access needed, and don't just elevate the whole process. Don't just sett full access to the whole folder - only open write access for single files.
WiX Permission Sample: There is a segment with information on ACL permissioning here: How to deny folder permission to Users with wix installer.
WiX Permission Elements: And here is another segment - mid page - (different ways to apply permissioning in WiX): Is WiX changing the permissions on my Notes.ini file?
WiX Permission Documentation: And the actual WiX documentation is here: http://wixtoolset.org/documentation/manual/v3/ (search for "permission" - recommend link in previous bullet point to understand the differences between the different elements).
7. Windows Service: In certain cases one can run the parts of an application that require elevated rights as a Windows service. Not an approach that I have seen very often, but possible. You then install the service to run as LocalSystem or an equivalent, elevated account (or using service accounts - see "other approaches" section - or this alternative answer). Maybe I can mention scheduled task as well - I have never tried to use a scheduled task for such a scenario.
8. Impersonate: I suppose you could impersonate an account with access rights to write to the location in question. I don't use this approach so I am unsure of the technical details, aspects and challenges. Just chalking it up as an option.
9. Virtualization Approaches: Just mentioning this. Various forms of virtualization - for example policies you can enable to allow file and registry write failures to be redirected to a writeable location (more along the lines of data redirection - with all the confusion that ensues - this is no solution - in fact Microsoft intends to remove the feature in future Windows version. Not sure of the state in Windows 10. MSDN on Registry Virtualization). Generally no problems solved, but several problems not recognized. Overall certain to cause confusion as people don't see where the data is written to, and the data is not shared among users - but user-specific. And there are full-on virtualization / data streaming like App-V and containers that allow full access. Not my speciality, and not my preference.
Please do not use this virtualization or data redirection nonsense (it is for legacy applications to not crash, not for new applications to use). I will still add a link to some technical details for how the feature actually works (there are a number of prerequisites that must be satisfied before this redirection works): log4net log file not visible in Windows explorer in application installation sub folder (recommended to show why this feature should never be used).
10. Registry HKCU: Last but not least one should mention that the traditional approach for settings management would be registry
keys stored per user if you want each user to be able to tweak them.
Linked below is an answer from way back on the topic of per-user file deployment and how it can be done in a package, along with some alternative network / database / cloud approaches.
It might be an involved read, but here it is - it essentially provides a few more permutations of the above possibilities:
Create folder and file on Current user profile, from Admin Profile
Some Links:
C++ MSI Package Administative Privileges (same issue, basically)
can give administration privileges to Application folder when creating windows installer
WiX Toolset: install file with specific permissions
Open project properties for the project that wix is triying to install.
go to security
and set the security settings as
You can also leverage .NET impersonation concept, if there is no other alternative location which doesn't require administrative privileges.
Here is the link to get the overview of the .Net impersonation.
How do you do Impersonation in .NET?
I wrote a VS12 .net4.5 .exe that copies itself to the user directory (unless it's executed from there) and creates a shortcut to the user directory .exe in shell:sendto.
Every time it's executed with the send to menu just one of my colleagues gets the smartscreen warning where he needs to click on "more information" and then "execute anyway".
In the .exe properties there is an Allow button, if you click it it disappears but once you close the .exe property dialogue and open it again the button is there again!How do I get rid of it?
I am often writing helpful little C# applications with different distribution strategies: Sometimes it's in a rar/zip archive and I put it on our NAS, sometimes I send it via email and sometimes it's transmitted with a data stick.
How can I reliably predict whether there will be a smartscreen warning?
I have read lots of unverified information about an invisible magical reputation value.
Is there truly no way to properly sign my applications to be sure there won't be a warning? We'd be ready to buy a certificate if we know for sure that it will remove the smartscreen warning.
Smartscreen is a technology from microsoft that establishes an internet connection to one of microsofts servers and checks if the exe that you are trying to execute is on a whitelist or correctly signed.
Therefor it will warn the user when executing all not fully signed and unknown applications.
You can use any official digital signing company to get a certificate (they cost something). One of the most popular is VeriSign. As far as I know this should stop the warnings from smartscreen.
Also you should use the signtool to create an assembly with a strong name. That gives the assembly a basic level of trust. However this will not stop Smartscreen from warning the user from executing your application.
http://msdn.microsoft.com/en-us/library/ms247123(v=vs.90).aspx
An assembly signed with a strong name is ensured to not have undergone any changes since the assembly got compiled. It therefor prevents viruses from infecting the assembly, that makes the computer trust the exe file more.
Is it possible to delete-protect a file/folder using Registry or using a custom written Windows Service in C#? Using Folder Permissions it is possible, but I am looking for a solution that even restricts the admin from deleting specific folders.
The requirement is that the administrator must not be easily track the nature of protection and/or may not be able to avert it easily. Obviously all administrators will be able to revert the procedure if the technique is clearly understood.
Like folder Permissions/OwnerShip Settings can easily be reset by an administrator. SO that is not an option.
Folder protection software can easily be uninstalled and show clear indication that a particular folder is protected by some special kind of software. So that too is not an option.
Most antivirus programs protect folders and files in Program Dir. Windows itself doesnt allow certain files such as registry files in c:\windows\system32\config to not even copied. Such a protection is desired for folders which allowse to read and write to files but not allow deletion. Similar functionality is desired. The protection has to seemless and invisible.
I do not want to use any protection features like FolderLock and Invisible secrets/PC Security and Desktop password etc. Moreover, the solution has to be something other than folder encryption.
The solution has to be OS-native so
** that it may implemented **
pro grammatically using C#/VB.Net.
Please help.
Obviously all administrators will be
able to revert the procedure if the
technique is clearly understood.
Please don't tell me your solution is going to rely on security by obscurity...
Anyway, if you don't trust people with administrative rights on the server not to do the right thing, then I suspect you are trying to solve the wrong problem. The problem you should be trying to solve is restricting access rights, and training those who have elevated privileges.
Well, i don't know what you are actually trying to achieve, one option to prevent the deletion is to keep the file open in write mode from your program. nobody will be able to delete it as long as it is open. This is why you are not able to delete windows registry files.
But this does mean that nobody else will be able to write to the file.
I am trying to write a test which, in it's fixtures Setup, it backs up a file and deletes the original, runs the test without the original present, then in the teardown, restores the original from the backup. The file is located in my %ProgramFiles% folder. I get an UnauthorizedAccessException on the fileInfo.Delete() statement. I have no problem deleting this file from another test project on the same machine that is not running from the Resharper Test Runner.
I can't move the file to somewhere else - it's ssapi.dll, an installed dll for Visual SourceSafe. (Yes, I'm doing something invasive in a Unit Test.)
It's the same user (me) for both ways -- I checked it via Task Manager. My user account is a member of the local Administrators group. What other factors are there which determine my "Authorization" to do something with a file?
RESOLVED: Though it doesn't answer my original question (which I'd still like to know the answer to), I have found a workaround for my testing purposes, using the System.Security.Permissions framewok, doing a Demand for FileIOPermissionAccess.Read in the app (non-test) code which requires the file (for an Interop call), and a Deny for the same in the test of that code which requires a scenario that that file is not there. This should work for now (and I love having learned a bit about the System.Security.Permissions namespace)!
Not really a solution, but I'd consider fixing this problem from a different angle.
You could perhaps consider changing the directory to %AppData% (you might need to make this change for you main application also).
It might solve your problem and also will see you well when you move to Vista, since UAC could stop you (or the application user) from using the %ProgramFiles% directory.
It is possible that ReSharper is running its Test Runner as a separate process, and that separate process is not using your Windows identity but, instead, another one with lower privileges.
You might be able to verify this opening Task Manager and checking Show processes from all users.
You can probably fix this by giving your user account full access to that folder.
Navigate to the folder in windows explorer. Right click on the folder and select properties. Select the security tab, then the Edit button, and add full control for yourself. Yes - I suppose it's a potential security issue, but you have to change the files in that directory, and you seem to know what you're doing, so it should work.
You could activate auditing for the file, and check the error message in the event log. Note that you have to turn on auditing in two places, once under Local Security Policy/Local Policies/Audit Policy and once on the file itself.
This would not solve the problem, but would at least help diagnose the problem.
Are you running Vista or Server 2008 with UAC turned on? If yes, this might be the cause - the test runner process might not be in "elevated" mode.