I am writing an IE Extension (BHO) in C#. When run in protected mode (IE's new UAC-compliant mode which forces all extensions to run at low-integrity), it fails because it cannot access user.config in the appdata folder.
Is there some way to mark files are readable by lower-integrity processes?
Failing that, is there some way to force the BHO to run at medium-level integrity?
Failing that, is there some way to create a low-integrity symlink in the low-integrity folders which points to a medium-integrity file in AppData?
Failing that, is there some way to force the application to use a user.config file in the LocalLow folder? How do I get the path for this folder in .net (it's not listed under Environment.SpecialFolder)? Will I be able to fall back with users running XP or who turn protected mode off, without losing all their user.config data?
There's one approach that is not especially elegant but you can start another (broker)process with medium level integrity which can do the 'dirty work' and use IPC to communicate with it. To make your life easier I would suggest you to use sockets for communication because they don't require security check which can be tricky when you have communication between processes with different integrity levels.
In order to skip UAC warning when you spawn new process you can modify BHO registration script and add few registry values that will inform IE to silently elevate new process to medium level.
You can find more information here: http://msdn.microsoft.com/en-us/library/bb250462(VS.85).aspx#wpm_elebp
I would start with the Protected Mode Internet Explorer Reference.
I suggest you to write your own SettingsProvider that saves files in System.IO.IsolatedStorage.
You get a one-shot privileged access during RegisterBHO. After that you are in protected mode.
If you need to change long term storage during the runtime of the BHO, I have found that the registry is the best place. Your changes will be only visible to you, but they will persist.
Related
Hi is it possible to prevent my .exe application on being renamed..?
here is the senario(my problem)
After i Run my program, (lets say i run MyApp.exe)
a unfriendly user suddenly for fun, renamed my MyApp.exe to ... lets say Goodtime.exe
after that. he log-off windows(xp) and then when my program is attempting to run on startup
MyApp.exe , i wont because it got renamed
is it possible to prevent this through codes?
thanks to anyone who would help =)
You can't really attempt to stop this. It's the user's computer and if they want to rename files on their computer they can do.
That is not possible.
However there is an alternative to do that.
You can set the user to have limited rights on his user account to the computer. In that case he cannot rename files in such a way he wanted. This is a restriction provided by the operating system in which only the administrators of the computer can set these restrictions to user accounts.
EDIT
What I mean here is if you are the administrator of the computer, as an alternative you can manually limit the privileges of the users who logs-in to the computer. For a better understanding on what I mean, please read the replies on my post. :)
You can place your application somewhere the user is less likely to go and rename it, like in the program files folder. But you can't stop them actually renaming the application.
If the user isn't an administrator on that machine they won't have permissions to rename files in the Program Files directory by default. One would hope that unfriendly users aren't administrators on the target machine (If they are, they can do a lot worse than renaming one application file).
You can check what name the executable has when it's being run.
But you cannot prevent a user from renaming it.
You might consider using clickonce publishing. For the life of me I can never guarantee I can find the ruddy application after installing it with clickonce so that might stop your friendly user messing with the app? ;-)
Here is some info on ClickOnce Publishing.
In essence, write an application, right click the project/solution, choose "Publish", then follow the wizard.
It won't guarantee the user won't be able to rename and mess with the files, but it'll make it harder.
By permissions way as most folks here explained.
Stupid and waste method is to have a daemon (Service) running accessing this file all time since system boot. That way system wont allow this executable to be renamed unless this daemon is stopped.
you can prevent renaming or moving your exe file while it is running.
Open the exe file within your exe file for reading and deny writing.
Keep this file open as long as it runs.
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.
When should the Windows Registry be used for per-user state, and when should we use the filesystem, particularly the user's AppData folder? (eg, C:\Users\USERNAME\AppData). Where does Isolated Storage come in?
Is there a pretty firm rule, or is it just a fuzzy thing, like "use the registry until it becomes too much data to store in the registry". or "use whatever you feel like using."
Are there Windows logo requirements that affect the decision?
If I use the AppData directory, how do I choose between Local, Roaming and LocalLow ?
edit: I just noticed these similar questions:
When and why should you store data in the Registry?
Registry vs Ini file for storing user-configurable app settings.
I will summarize replies.
If you have a small number of key/value pairs and the values aren't big the registry is great - and you don't care about xcopy deployment - then use the registry (I know this isn't exact, but it's usually obvious when working with the registry becomes a pain).
If you want xcopy deployment the data must be in the same folder as the program obviously - but the program can be somewhere under the AppData folder, it doesn't have to be under "program files".
Use isolated storage only when you need it or have to use it - for example ClickOnce.
Otherwise use AppData\Roaming, use Local or LocalLow only if you have a good reason.
EDIT: Here is the difference between Roaming, Local and LocalLow:
Windows has a little known feature called "roaming profiles", the general idea is that in a corporate environment with this feature enabled any user can use any computer.
When a user logs in his private settings are downloaded from the server and when he logs out his settings are uploaded back to the server (the actual process is more complicated, obviously).
Files in the User's "Roaming" folder in Vista or "Application Data" in XP move around with the user - so any settings and data should be stored there.
Files under "Local" and "LocalLow" in vista and "Local Settings" in XP do not, so it's a good place for temp files, things that are tied to the specific computer or data that can be recalculated.
In Vista, as part of the new security features we all know and love, you can have programs running in "low integrity mode" (for example IE in protected mode), those programs are running with reduced privileges and can't access files in the user's profile - except for files under the "LocalLow" folder.
So, in conclusion, files stored in "LocalLow" are inherently insecure and files in "Local"/"Local Settings" are likely to be unavailable in some large companies - so unless you have good reason and know exactly what you are doing go with "Roaming"/"Application Data".
Don't clutter up my Registry thank you.
Use isolated storage, thats what it's for.
See Was The Windows Registry a Good Idea? On Jeffs Blog...
You might want to consider Isolated Storage.
I don't know whether there is a firm rule, but but one thing to consider is that the registry is transacted -- it is safer for concurrent read/write operations. So, if your user data might be written by multiple threads at run time (or if you have multiple exe's in your product package), consider using the registry.
History:
One reason (as I heard it) that MS went from .ini files to the registry was precisely to try to handle the concurrent access problem.
.Net (sort of) went back to .ini files in the form of xml .config files, however those config files are not supposed to be written to at runtime (or at least not if there is a chance of concurrent writers/readers).
More info: http://blogs.msdn.com/oldnewthing/archive/2007/11/26/6523907.aspx
I need to store log files and configuration files for my application. Where is the best place to store them?
Right now, I'm just using the current directory, which ends up putting them in the Program Files directory where my program lives.
The log files will probably be accessed by the user somewhat regularly, so %APPDATA% seems a little hard to get to.
Is a directory under %USERPROFILE%\My Documents the best? It needs to work for all versions of Windows, from 2000 forward.
If you're not using ConfigurationManager to manage your application and user settings, you should be. The configuration toolkit in the .NET Framework is remarkably well thought out, and the Visual Studio tools that interoperate with it are too.
The default behavior of ConfigurationManager puts both invariant (application) and modifiable (user) settings in the right places: the application settings go in the application folder, and the user settings go in System.Environment.SpecialFolder.LocalApplicationData. It works properly under all versions of Windows that support .NET.
As for log files, System.Environment.SpecialFolder.LocalApplicationData is generally the place that you want to put them, because it's guaranteed to be user-writeable.
There are certainly cases where you wouldn't - for instance, if you want to write files to a network share so that you easily can access them remotely. There's a pretty wide range of ways to implement that, but most of them start with creating an application setting that contains the path to the shared folder. All of them involve administration.
I have a couple of complaints about ConfigurationManager and the VS tools: there needs to be better high-level documentation than there is, and better documentation of the VS-generated Settings class. The mechanism by which the app.config file turns into the application configuration file in the target build directory is opaque (and the source of one of the most frequently asked questions of all: "what happened to my connection string?"). And if there's a way of creating settings that don't have default values, I haven't found it.
Note: You can get the path to the LocalApplicationData folder in .NET by using the following function:
string strPath=System.Environment.GetFolderPath(System.Environment.SpecialFolder.LocalApplicationData);
For application settings - use System.Environment.SpecialFolder.ApplicationData - this is where a roaming profile data is stored, so it allows your user to log and work from different machines in the domain.
For log files - System.Environment.SpecialFolder.LocalApplicationData
The accepted answer notes that for log files the following is a good spot.
System.Environment.SpecialFolder.LocalApplicationData This equates to a path of C:\Users\[User]\AppData\Roaming which you can see is user specific. Like the accepted answer mentions this is a guaranteed user-writeable location and can be useful for certain situations
However in a web application environment you may be running your application under a network account and you or a coworker may need to try and track down where exactly those logs are going per application. I personally like to use the non user specific location enumeration of
System.Environment.SpecialFolder.CommonApplicationData which equates to C:\ProgramData. Yes, you will need to specify access rights for any folders you create, but it's usually a one time deal and then all of your application logs can live in one happy location.
Additionally, while looking around the Internet, there is a project out there to programatically set write access to folders you create within CommonApplicationData, Allow write/modify access to CommonApplicationData.
To be honest %appdata% is still the best place to place your config files and log files, as it serves the purpose of a placeholder to store your application data. It should not be that hard to access, just write %appdata% in explorer and you will be directed straight to your %appdata% directory.
Do not store config files in the application folder, Microsoft has stated this is NOT the ideal location. Windows has been moving towards blocking writing to C:\Program Files\ and you'll find in Vista any application that tries to write here, will fire up a UAC warning.
Windows 7 will allow users to customize what UAC popups they use (expect some power users to block most of them) and your app will fail/freeze if the user never approves this write attempt.
If you use the proper userprofile and appdata variables, then Win 2000, XP, Vista, and Win7 will map the data to the proper write friendly folder, with no UAC popups.
You can use SHGetSpecialFolderPath:
int MAX_PATH = 255;
CString m_strMyPath;
SHGetSpecialFolderPath(NULL, m_strMyPath.GetBuffer(MAX_PATH), CSIDL_COMMON_APPDATA, TRUE);
This will specify the 'special folder path' which you can safely write logs to for windows:
For XP: C:\Documents and Settings\All Users\Application Data
For Vista: C:\ProgramData
Check the MSDN page here: http://msdn.microsoft.com/en-us/library/bb762204(VS.85).aspx
The best answer depends on the nature of the logs and configurations. If they are program-wide, and don't need to survive uninstallation of the application, then I think they're fine where they are. If the logs and configurations are user specific, or need to survive uninstallation, then they belong somewhere under %USERPROFILE% - %APPDATA% being the 'proper' base directory for this type of thing.
I use the Isolation Storage for configuration. You can also use the Temp folder to store temporary information like log.
I have a winform application to compress and move some files. When I try to access a path on my desktop, I get an unauthorisedaccess exception. I am running visual studio as administrator (says that in the program bar) and I am a full admin on my machine (can access other accounts, etc).
How can I acess this path (folder)? One of the problems I have is the folder keeps setting itself to readonly.
Thanks
The readonly flag can be cleared by anyone with write access. If that is all then you will just need to set file attributes. However if the files ACL is blocking you (and it is easy to create an ACL that does not allow administrators) your options are more limited.
Start by finding out why the file keeps being set to read only, because if something else is updating the file you will have to coordinate with that other process otherwise all sorts of problems are likely to occur.
Best tool to see what is happening to a file is Process Monitor from SysInternals.