Is there a way to lunch a process in C# with limited read file permissions?
For example: Launch notepad.exe so it is unable to read C:\temp\ but can read C:\abc.
I have code to launch a process in low integrity mode but this only stops the process from writing files. It can still read most files on the disk.
I have code to launch a process in low integrity mode but this only stops the process from writing files. It can still read most files on the disk.
Yes, and as well it should be able to. The solution here is not to modify the privileges of the application, but rather to modify the permissions of the individual files.
You can take advantage of discrete user accounts to help you keep things organized. Windows has lots of file security features built in. Ask more questions about that on Server Fault. This is not a programming-related problem, it's an operating system security configuration issue.
Code Access Security appears to be what you are looking for.
Related
i'm making a small project. it's Windows Form Application. i got some sources in a folder (C:/sources). When my program runs, it uses sources from the folder. Currently i can edit the folder by windows explorer, it can cause errors for my program. So i want to lock the folder (C:/sources) from being edited/renamed/deleted when my program runs. How to do so?
EDIT;
Is it possible to show a message like this when user has tried to edit the folder:
"the action cannot be completed because the folder or a file in it is open in another program"
the program that we are talking about is mine..
There are a couple of approaches that you could venture and they vary in difficulty of implementation. It all depends on how important this task is for you. But, before discussing these options; can't you embed those resources in your WinForms application instead? If this is not an option then you can do one of the following:
Write a device driver that can prohibit the access of such resources if your application is running. There are fallbacks to this approach. For example one can impersonate your application by having the same name. But, am not getting in to too much details in trying to break any approach as I am trying to address possible solutions to the current problem. There are different types of drivers that you can consider. Probably the simplest form of this approach would be to implement a mini-filter driver.
Hook certain API's like CreateFile(), NtCreateFile(), ZwCreateFile() although there are many ways to circumvent such mechanism of defense. But, again we are only venturing what you can do to address this constraint of yours.
Open these resources directly from your application and lock it exclusively. For example:
File.Open("test.txt", FileMode.Open, FileAccess.Read, FileShare.None);
as this will result in people getting the message that you desire if they try to open the file.
Maybe you can give more information on what these resources are and we can help you determine which is the best way to protect your files in a reasonable fashion?
Although I don't believe it's the best idea to have files that are critical to the application in a open area like the C: drive, I would look into NTFS file permissions and set the folder to read only, but this wont stop administrative users
See these two posts
restrict access to folder outside of program c#
Setting NTFS permissions in C#.NET
I want to develop the application which logs the files / directories accessed on the machine.
e.g. I go to D:\ and into a folder documents and open a word file. I want my application to create a log in the following format:
D:\ Opened
D:\documents Opened
D:\documents\secret.docx Opened
I've used FileSystemWatcher to achieve the other type of file system activity but unable to get events for accessing this.
sounds like you wanna do a FileMon program like sys internals. in their website Mark tells about the way FileMon works so you can get some inspiration by reading the article.
also see here: How do you monitor file access and changes on a file server by user name?
Not sure this sort of monitoring can be achieved with filesystemwatcher as it is aimed at monitoring changes I believe. You could use filesystem Auditing (by going into advanced security settings) which will log events in eventlog and you can pull it from there.
Most viable option is use of file system filter driver. Such driver gives you fine-grain control over all requests going to particular file system. The only issue with this approach is complexity of developing such driver in kernel mode.
While experimenting with FileSystemWatcher, I've found out that it somehow surpasses my user account's permissions to files and folders, and will raise change events with information about what has changed in files and folders that you don't even have access to.
I have two questions about that:
1) Why does this happen ?
2) Is this a problem in the AD configuration ? how do I fix it ?
3) Is there any way to gather these files, or even create a FileSystemInfo of them to get more info about the files (not only the changes made on them) ?
As far as I've tried, only the FileSystemWatcher immune to the restrictions, I can't run any other thing over it, here's a list of what I've tried:
File.Exists
Directory.Exists
FileInfo instance on found files
DirectoryInfo instance on found files
File.Copy
File.Delete
Update: Tried helge's solution, with somethin similar to what he's sugested, not through windows' api, but through the command prompt:
robocopy /B \myserver\folder c:\somefolder
Best command name ever.
You can check through robocopy that /B stands for "backup mode", which is what helge's suggested that would be the cause to this security surpassing.
I'll try anything, I want to find out what exactly causes FileSystemWatcher to be able to watch folders I do not have permission to open. Knowing why, I want to learn both how to block FileSystemWatcher, and how to gather found files.
I'd make a survey if I was with my personal account. Please, can someone help me ? I'll write a blog post about the solution, among other things that might help anyone with the same doubt in the future.
According to this answer on SO the FileSystemWatcher is based on the API function ReadDirectoryChangesW. If that is true it explains the behavior witnessed by you - and why that is not a security hole.
As documented on MSDN ReadDirectoryChangesW needs the privilege SeBackupPrivilege (which is requested by the parameter FILE_FLAG_BACKUP_SEMANTICS to CreateFile). If a file is opened in that mode, the returned handle grants full access to the file, circumventing access checks. This feature is designed for backup programs that need to be able to read everything on disk regardless of permissions.
This is not a security hole because the privilege SeBackupPrivilege which is required for this to work is by default granted to administrators only. Administrators, and in fact anyone with physical access to a machine, are always capable of taking control of and reading every file - unless it is encrypted.
As to which functions can be used to access files in backup mode: There is at least BackupRead for reading. Enumeration is easily possible with FindFirstFile/FindNextFile. Of course this requires the real Windows API, not the crippled .NET file system functions.
I've been working on a program to monitor a network folder to find out which spreadsheets our company uses are the most popular. I'm using the FileSystemWatcher class in C# to do the monitoring. I've noticed I'm getting updates to files that are in folders that my user does not have permission to browse. I understand that my software is subscribing to a list of updates done by other system software and not actually browsing those files itself, but is this functionality intentional or is it a bug?
The FileSystemWatcher is intended to monitor for any changes, not just a user opening the file.
EDIT: I'm pretty sure this is done by design. Think of trying to have a program check a network location for updates. You might not want the user to have access to that file location, but you want to be able to check for file changes, and download new files when they are available.
You may also have programs (like BizTalk) generating or editing files that other programs need to access, so these other programs just sit there and watch for file changes.
Is there a way to read a locked file across a network given that you are the machine admin on the remote machine? I haven't been able to read the locked file locally, and attempting it over the network adds another layer of difficulty.
Depending on the type of lock (read only vs exclusive) it should be possible to copy the file first, then you can work with the unlocked copy.
You should be able to do that in a background thread. If you really like threading, have the file watcher start the read process once the copy is complete (although that might be overkill)
There is no problems to READ the file locally or remotely if it's not locked EXCLUSIVELY or READ/WRITE. If the file is locked - your administrative rights will not help (even if you're GOD :-). If the file is not locked fore READ (you can check it by opening it with a notepad) - you can read it locally and remotely (it doesn't matter, unless your network share is putting some extra restrictions).