I'm working on a C++ application that stores (and frequently accesses) its data across many files within a single directory via numerous classes, database libraries, etc. I would like to start encrypting all this data on disk using a key managed by the application.
On windows, programmatically enabling EFS for the directory would be perfect if the application could set the encryption key directly rather than using one based on the logged-in user's password. This does not seem possible.
Because there are numerous places in the code that read/write files, some with full random-access, a library that exports something akin to the OS file operation API would be easiest in the absence of direct OS support.
Windows is the biggest user base but something usable on Mac and Linux would be a big plus.
Any suggestions?
Configure the application to run as a service account, intended only for it. Then, configure EFS. Since the application's service account will own the files, its user-specific keys should be the only valid EFS keys for it, so only the application (which will be the only thing running under this new service account) will be able to access the files.
Have you considered storing the files in an encrypted archive, such as a zip file? Not knowing what language you're working in makes it difficult to give a more specific answer.
I am not an expert but I have a few suggestions,
('user' is considered Male here)
In Windows, when an user is logged in, he will have all the rights to manipulate a file or folder which belongs to him.
But, if he tries to manipulate files or folders which belong to other users, he is not allowed to do so. So, he can't manipulate other user's files.
If the user is administrator, he will have all the rights to manipulate the file.
In your case, I believe the user is not administrator.
So, I suggest to you to:
Create a user for this application, say Bob(Bob is not the user who is going to use this application).
Then you create a folder to store your files and give all permission only to Bob(and the admin).
For all others, there no permission to do anything to the folder.
Your application must be installed by administrator.
When you start, Your application asks Bob's password from current user.
If the password is correct,
Using your application allow full access folder permission to the current user. Then application can work as you wish.
If the user quits the application,
Remove all permission for current user so that after quitting this application others can't access that content.
But Administrator can still access this content.
This is similar like Linux user management.
When you are getting a shell you can change user using su username when finishes the work and he quits the shell then others can't use those files. But root user can do anything in Linux.
But there is one problem.
Administrator can get full content and access since he can modify the permissions.
To disallow this, save the files by zipping using any technique and by using a password. That password is only known by the user who uses it. Before saving a file to the folder, zip it using a password. Before using the file, unzip it using the password.
If the zipping password is same as user password, then there is a problem.
The administrator can reset user password to something and open his account.
To prevent this you can use the following technique:
Use zip password as reverse of user password, so that if his password is 1234 the zipping password is 4321, or use hash value of user password as zipping password.
If the zip password is hash value like MD5 hash or SHA-1 then brute force on zip file won't work due to the password length.
I don't know if this is a working solution or not or if this can be implemented or not.
But you can take some ideas out of this, if you think there is some good ideas in this.
Unless I've missed something in your question, TrueCrypt seems to be an ideal solution for you.
It will allow to:
Utilize existing OS file API (as the mounted volume will behave just like regular volume)
Programmatically manage access key (password)
Limit access to the mounted volume (by OS mechanics)
Utilize same principles on all the platforms (Windows, Mac, Linux)
Or, if you want, you can encrypt/decrypt individual files with it.
There's a number of examples on how to use it around.
Related
Here is the issue that I am having,
I have a C++ application that runs by writing data to .txt files and I want to create an MSI Package for the application.
When I build and run my app all is fine but when I run my MSI Setup File the created application does get granted the correct privileges to function.
I can't find a way to allow the app to write to the .txt files needed even if I include them in the package and set them as system files.
If I "Run as administrator" all is well but that isn't really plausible as I need it to function while "Running as User".
Is there anyway to prompt the user while installing to agree to an install with admin rights, so it doesn't have to be done manually before a prompt each launch.
Anything that can get my code running again would be brilliant, thanks.
Longer Writeup: System.UnauthorizedAccessException while running .exe under program files (several other options in addition to the ones listed below).
Per-User Folder: I would think you should install the files in question to a per-user folder (writeable for user - for example My Documents), or as templates to a per-machine folder (not writeable for normal users - for example %ProgramFiles%) and then have your application copy the templates from the per-machine location to the current user's My Documents folder - for example. Then you write to the files there - where a regular user will have write access. I suppose you could also write to a network share which is set up for users to have access.
Elevation: It is possible, to require the application to run elevated (link might be outdated - for .NET it is slightly different), but this is a horrible approach for something as simple as writing to text files. I would never require such elevation. Elevated rights are pervasive, and you don't want your application to run with the keys to the city - you become a hacker target and bugs in your tool become armed and dangerous.
ACL Modification: It is also possible to install the text files to a per-machine location and apply ACL permissioning to them so that they are writeable for regular users even if they don't have elevated rights. There is some information on how to do this here (bullet point 2). This approach is frowned upon in this day and age, but it will work. Be on the alert that your ACL permissioning shouldn't be too tight, in case you write to a new file, delete the old one and rename the new file to the old name during your write operation - you need file create in addition to file write obviously - there is very fine-grained control in NTFS. GenericWrite should do the trick I think.
Some Links (loosely connected, added for easy retrieval):
Create folder and file on Current user profile, from Admin Profile
Why is it a good idea to limit deployment of files to the user-profile or HKCU when using MSI?
Create a .config folder in the user folder
There is no connection at all between the install of an application and the running of an application regarding privileges. In other words there is nothing you can do in an MSI install that grants elevated privileges to the app being installed. It would be a massive security breach if a limited user could create an MSI setup that then installed an app that ran elevated.
So this question is actually nothing to do with Windows Installer - it's about whether you require users to be limited users or elevated users. If it's acceptable that users must be privileged, then you give the app an elevation manifest. If limited users will use it, then all writes or modifications to files or registry entries must be to locations available to limited users. It also means that the app won't be able to perform privileged operations, such as starting or stopping services.
I maintain a large Windows C++ Application that installs with nullsoft nsis. Installation is quick and simple (less than 1 minute).
Some users in large companies do not have administration privileges and they have to order costly 3rd party services to update their installation. Therefore some of them only update once a year, while we ship every month and sometimes fix important bugs etc.
So we are thinking about automatic updates that do not require elevated administration rights. Mozilla and Adobe do this as well as others. As far as i can see an the Mozilla XULRunner site they install a service which then in turn can run a update without forcing the user to enter a administration password. I also found Googles Omaha but it is not clear about the administrator privileges ("Support for restricted user environments; for example, users without administrator privileges "..."This requires the user has administrator privileges.").
So far i have not found exact answers to these questions:
What steps do we have to take in order to establish such a mechanism?
Can we keep on with nsis?
What server infrastructure is requested?
Your application should check for updates on your server/website and get the download link.
This should be pretty easy if you maintain a text file/page with fixed hyperlink.
This hyperlink can be hard-coded in your application.
If it detects a version newer than the current version then download the files.
Along with these files there should be instructions for which files to replace and Which files are to be added at what location, etc.
Now whether or not you need admin privileges depends on where you need to place the updated files. If the target folder has some restrictions then it would be difficult to update in the same session. So you may have to launch a dummy exe which asks the user for admin privileges during startup. Now you can copy the updated files to your desired location without much pain.
Is it possible to select such a security descriptor using a DACL string such that the file can only be opened by a Windows Service, but not by an ordinary process, even if the process is run by the local Administrator account?
To clarify, I just need to make it reasonably hard for a non-technical user to open it in NotePad and tamper with it. It doesn't need to work against a programmer willing to dedicate a month of his life to reverse engineering and cracking it.
I prefer to achieve this using DACL instead of locking the file because then my windows service doesn't need to run all the time for the file to be protected.
Local administrator account = God (at least on the box). There's no way to do this.
You can define a special privileged account for your service to run under, and make the ACLs on the protected file only allow access by that user (and all machine admins). You can disallow interactive login using that service account.
If your primary concern is tampering by interactive users, you may need a policy whereby the local user does not run by default with local admin rights. Unfortunately you cannot allow 'partial' local admin rights - it's all or nothing.
I don't know enough about DACLs to say whether or how you can accomplish what you want with those. I can think of a couple things you can do to make it harder for someone to tamper with the file, in addition to restricting it to the local administrator account:
Have your service start automatically, and open the file immediately with no sharing options. As long as your service has it open, another process won't be able to open it.
Compute a hash of the file contents plus a salt hardcoded into your service and store it somewhere else, e.g., in another file, in the registry, or even online. Next time you open the file, verify the hash, which will tell you if someone tampered with the file since the last time you opened it.
These are not foolproof by any stretch, but it sounds like your goal is simply to make it harder. There's no foolproof method to stop a user with administrator privileges.
I need to setup a process to update a database table with user supplied CSV-data (running Coldfusion 8/MySQL 5.0.88).
I'm not sure about the best way to do this.
Should I give users FTP-access to my system, generate a directory for every user and upload files from there, or should I pick files up from external locations, so the user has to setup an FTP folder my system can access. I'm sort of leaning towards the 2nd way and wanted to set this up using cfschedule and cfftp, but I'm not sure this is the best way to go forward. Security wise, I'm mor inclined to have users specify an FTP location, from where I pull, rather than handing out and maintaing FTP folders for every user.
Question:
Which approach is better both in terms of security and automation?
Thanks for input!
I wouldn't use either approach. I would give the users a web page to upload their csv files. The cf page that accepts the files would place them into a specific folder and make sure they have unique filenames. The cffile tag will help you with that.
The scheduled job would start with a cfdirectory tag on the target folder. This creates a query object. Loop through it and do what you have to do with each file.
Remember to check for the correct file extension. Then look at the first line of the file to ensure it matches the expected format.
Once you have finished processing the file, do something with it so that you don't process it again on the next scheduled job.
Setting up a custom FTP server is certainly a possibility, since you are able to create users, and give them privileges (automated). It is also secure.
But I don't know the best place to start if you don't have any experience with setting up a FTP server.
Try https://www.dropbox.com/
a.)Create a dropbox account,send invites to your users/clients.
b.)You can upload files/folders into dropbox,your clients/users can access it from their
dropbox account/dropbox desktop app..
c.)Your users/clients can upload files/folders and you can access it from your dropbox
website account/desktop app.
Dropbox is rank 1 software, better in security and automation.
Other solutions:
Best solution GOOGLE DRIVE(5gb free)
create a new gmail account,give ur id and password to your users.ask them to open google drive and import/export files.or try skydrive(25gb free)
http://www.syncplicity.com/
https://www.cubby.com/
http://www.huddle.com/?source=cj&aff=4003003
http://www.egnyte.com/
http://www.sharefile.com/
Those all reside in the root\RSOP\Computer namespace. The only class from which I got non-empty results is RSOP_RegistryPolicySetting, and that one only gave me settings for Windows Update and System Restore configuration.
I do know there are password policies in our network (age, length etc), but queries on the following classes only gave empty resilts:
RSOP_ScriptPolicySetting
RSOP_SecuritySettingNumeric
RSOP_SecuritySettingBoolean
RSOP_SecuritySettingString
Does it have to be via WMI?
If you're running a domain, Microsoft's Scripting Guys have an article How Long Until My Password Expires?... but it uses ADSI to read policies from Active Directory, rather than policies on the local machine.