I'm using a third party SDK, and one of the method goes as following:
void ReadData(string filePath);
As you might have guessed, it requires a filename for the method.
I do not wish having to drop a (sensitive) file into the HDD, then use its filename as the parameter.
I was wondering if there is some way to create an isolated storage space from the user, so I can drop any files I want in there without worrying about people finding it?
EDIT: Strictly for Windows OS only.
Just don't worry about it.
You seem to have some misconception about who owns the computer and the data. The user does.
If you're worried about other users getting access to the file, use the user's private documents or appdata directory, the ACL will prevent unprivileged users from getting to it.
But if your business model relies on denying a user access to the data inside their own computer, you need to rethink that. There isn't any API to save a flawed business model.
since the API of you call asks for a filename instead of a file, we have to asume that you really need a file, not a file-like-object.
A more specific name to the method would be "ReadDataFromFile". Take a look, is there another method that accepts the data itself, instead of a filename?
You are trying to transfer trust from the file owner to/and only to the program that does the call, you are mentioning in your question. So, if that all fails, take a look at File ACLs to restrict the access to the sensitive data, e.g.: https://superuser.com/questions/246280/what-are-windows-acls or http://msdn.microsoft.com/en-us/library/aa374872%28v=vs.85%29.aspx
You still have to put the sensitive file on disk (an worry about deleting it later), but access would be restricted.
Related
I want to make a simple console application that will execute some usefull functions that I regularly use for my school (to check if a number is prime, to write factors of a number, solve a quadratic equation etc.).
But as I was making it I decided to add some details about the app to make the user interface prettier: to write the name of the app, version ...
I came to an idea to have an admin password which I can type in and then I can modify those extra details or change the password.
But if I have a password that I store like a const variable or a regular variable const string password = "blablabla;" every time I run the app it will have the same password "blablabla" so is there a way to somehow change the password and other extra data so the program saves the new values permanently?
I thought to save all those extra information in some file and then read them from it every time, but then if the file is changed then the data will be to and I don't want that. I want to change the data only with an admin password. I also thought I can encrypt those information but still thay can be easely changed.
I also thought that the program can open the source code and then modify those initialized values, but then I need to compile that file and I also don't want that.
I only want an .exe app that will run and can change those information permanently with an admin password.
Does anyone now if this can be done and how?
I'm writing this app in C++.
Thank you in advance
is there a way to somehow change the password and other extra data so the program saves the new values permanently?
In theory, you may be able to modify the constants in the data segment of the executable. How to do that is dependent on the executable format. But I would consider that a kludgy workaround and it would be difficult to prevent someone from modifying the executable without the password. What you really want is variables. And you have a good idea for how to initialize the variables:
I thought to save all those extra information in some file
A good idea. Simple solution, probably appropriate for the scope of your app.
if the file is changed then the data will be to and I don't want that. I want to change the data only with an admin password.
Then protect the file somehow. You could, for example not give anyone write permission to the file. Or if you're paranoid (this is just a small console app just for you, right?) encrypt it...
I also thought I can encrypt those information but still thay can be easely changed.
It won't be easy without the key. Sure they can modify the cryptotext, resulting in garbage data, but if you are concerned about that, realize that if they have write access to your files, they can just delete the program itself.
If you want to go this far though, consider storing your data in a full-fledged database which will have authentication and encryption already implemented.
You need to add Windows resources to your application and then update them run-time.
https://msdn.microsoft.com/en-us/library/ms648004%28v=vs.85%29.aspx
Can we add metadata to unlink/remove a file after x-time automatically. That is system automatically removes that file, if it finds that particular metadata attached with that file
Note- file can be present at any location, and user may move that file anywhere on their system, but based on that metadata file should get deleted(i.e system should call unlink/remove) for that file.
Is there a cocoa/objective-c/c++ api to set such metadata/attributes of a file?
The main point is i am creating an application through which i am providing some trial files to the user, and those files are also usable by other application which recognises them. After trial expiry, i want to delete those files, but user can always move my files to a different location and use them forever, how to protect those files from permanent use?
No, there is no built-in mechanism to auto-delete a file based on some metadata.
You could add the feature yourself, with an accompanying agent that would trawl for files with the metadata and delete them when the time came.
If you are doing this for good housekeeping you can follow #Petesh answer.
If you are doing this because you really want those files gone then no. The user could move the file to a USB stick and remove it, or edit the metadata, etc.
Your earlier question "Completely restricting all types of access to a folder" seems to addressing the same issue and the suggestions are the same as given there - use encryption or implement your own file system.
E.g. have a special "trial file" format which is the same as the ordinary format - which is readable by other apps - but encrypted and includes an expiry date. Your app then decrypts the file, checks the date, and either does its thing or reports to the user the file is out of date.
The system isn't unbreakable, but its a reasonable barrier - easy for you to do, too hard for the average user to break.
I am making a cocoa application, which creates some folders at my specified location in the user's environment. Now i want to protect these folders from any type of read, write, copy, drag access from all type of users(i.e Not accessible for admin and non-admin users).Is there a way to protect these folders from any type of access.
Can we use, NSFileManager method -setAttributes:OfItemAtPath:error:
But i am not sure on attributes dictionary of this method.
Basically i want to provide trail of some files to the user (let's say 1 day trial), and removing those files as soon as the trail expires, and all those files are placed inside a certain folder in the user's environment. What should be the best approach i should use to protect those files?
You could use NSFileManager setAttributes:OfItemAtPath:error: with the attributes key NSFilePosixPermissions. With this, you can set the Unix file permissions of your folder by specifying them with an integer value that represents the permission bit pattern. Setting it to zero would mean no access at all to that directory:
NSDictionary *attribs = [NSDictionary dictionaryWithObjectsAndKeys:
NSFilePosixPermissions, [NSNumber numberWithInt:0], nil];
However, it would still be possible to move or rename that directory.
Short answer: No. Someone with elevated privileges can do just about anything. No playing with permissions will get you there and still allow your application to access the files.
If you could just turn off all access rights how would you expect your own application to access the files? Turning on the access rights is itself an access right...
Longer answer: Maybe. This depends on what you are trying to achieve. Do you really want to stop the files being copied, or just their contents accessed?
Encryption can be used to protect content (e.g. at the file level, using an encrypted sparsebundle image, etc.), storing identification information in a file can alert you that you’re using a copy (e.g. see what happens if you move/copy a VMWare virtual machine or recreate a Google Drive folder), etc.
And you can always implement your own filesystem using FUSE; and prevent copying, access, etc. by your own mechanism, however the filesystem as a whole could still be copied (i.e. effectively implement your own equivalent of an encrypted sparsebundle via FUSE and implement your own access mechanism).
What are you trying to achieve? If you spell that out folk might be able to suggest alternative solutions.
See also this question on preventing root from writing to files.
I've attempted to do this using GetEffectiveRightsFromAcl, but it's not returning the correct access mask for files that are denied to me due to a group I'm part of.
For example, I have a file, unreadable.txt. If I deny write access to unreadable.txt for my current user, the access mask correctly shows that I don't have write access. However, if I instead deny write access for the 'Authenticated Users' group, the access mask implies that I have full access (which I don't).
My alternative was to manually iterate the Ace list and compare my SID with each entry, but I'm unable to find a clean or easy way to check if the Ace is for a group, and if the current user is part of that group.
As an extension, the file may not exist (i.e. it's a new file, about to be written), in which case the access to the directory needs to be checked.
Is there any good solution to this? It seems like there should exist an easier way to do this, without actually trying to read/write to the file in question.
Use AccessCheck instead, as recommended by the knowledge base article on the Limitations of the GetEffectiveRightsFromAcl API.
Just try to open the file with the desired mode using CreateFile - if it succeeds you know you have the access rights. You don't actually have to write anything to the file, just close it right away.
I want to verify if the text log files created by my program being run at my customer's site have been tampered with. How do you suggest I go about doing this? I searched a bunch here and google but couldn't find my answer. Thanks!
Edit: After reading all the suggestions so far here are my thoughts. I want to keep it simple, and since the customer isn't that computer savy, I think it is safe to embed the salt in the binary. I'll continue to search for a simple solution using the keywords "salt checksum hash" etc and post back here once I find one.
Obligatory preamble: How much is at stake here? You must assume that tampering will be possible, but that you can make it very difficult if you spend enough time and money. So: how much is it worth to you?
That said:
Since it's your code writing the file, you can write it out encrypted. If you need it to be human readable, you can keep a second encrypted copy, or a second file containing only a hash, or write a hash value for every entry. (The hash must contain a "secret" key, of course.) If this is too risky, consider transmitting hashes or checksums or the log itself to other servers. And so forth.
This is a quite difficult thing to do, unless you can somehow protect the keypair used to sign the data. Signing the data requires a private key, and if that key is on a machine, a person can simply alter the data or create new data, and use that private key to sign the data. You can keep the private key on a "secure" machine, but then how do you guarantee that the data hadn't been tampered with before it left the original machine?
Of course, if you are protecting only data in motion, things get a lot easier.
Signing data is easy, if you can protect the private key.
Once you've worked out the higher-level theory that ensures security, take a look at GPGME to do the signing.
You may put a checksum as a prefix to each of your file lines, using an algorithm like adler-32 or something.
If you do not want to put binary code in your log files, use an encode64 method to convert the checksum to non binary data. So, you may discard only the lines that have been tampered.
It really depends on what you are trying to achieve, what is at stakes and what are the constraints.
Fundamentally: what you are asking for is just plain impossible (in isolation).
Now, it's a matter of complicating the life of the persons trying to modify the file so that it'll cost them more to modify it than what they could earn by doing the modification. Of course it means that hackers motivated by the sole goal of cracking in your measures of protection will not be deterred that much...
Assuming it should work on a standalone computer (no network), it is, as I said, impossible. Whatever the process you use, whatever the key / algorithm, this is ultimately embedded in the binary, which is exposed to the scrutiny of the would-be hacker. It's possible to deassemble it, it's possible to examine it with hex-readers, it's possible to probe it with different inputs, plug in a debugger etc... Your only option is thus to make debugging / examination a pain by breaking down the logic, using debug detection to change the paths, and if you are very good using self-modifying code. It does not mean it'll become impossible to tamper with the process, it barely means it should become difficult enough that any attacker will abandon.
If you have a network at your disposal, you can store a hash on a distant (under your control) drive, and then compare the hash. 2 difficulties here:
Storing (how to ensure it is your binary ?)
Retrieving (how to ensure you are talking to the right server ?)
And of course, in both cases, beware of the man in the middle syndroms...
One last bit of advice: if you need security, you'll need to consult a real expert, don't rely on some strange guys (like myself) talking on a forum. We're amateurs.
It's your file and your program which is allowed to modify it. When this being the case, there is one simple solution. (If you can afford to put your log file into a seperate folder)
Note:
You can have all your log files placed into a seperate folder. For eg, in my appplication, we have lot of DLLs, each having it's own log files and ofcourse application has its own.
So have a seperate process running in the background and monitors the folder for any changes notifications like
change in file size
attempt to rename the file or folder
delete the file
etc...
Based on this notification, you can certify whether the file is changed or not!
(As you and others may be guessing, even your process & dlls will change these files that can also lead to a notification. You need to synchronize this action smartly. That's it)
Window API to monitor folder in given below:
HANDLE FindFirstChangeNotification(
LPCTSTR lpPathName,
BOOL bWatchSubtree,
DWORD dwNotifyFilter
);
lpPathName:
Path to the log directory.
bWatchSubtree:
Watch subfolder or not (0 or 1)
dwNotifyFilter:
Filter conditions that satisfy a change notification wait. This parameter can be one or more of the following values.
FILE_NOTIFY_CHANGE_FILE_NAME
FILE_NOTIFY_CHANGE_DIR_NAME
FILE_NOTIFY_CHANGE_SIZE
FILE_NOTIFY_CHANGE_SECURITY
etc...
(Check MSDN)
How to make it work?
Suspect A: Our process
Suspect X: Other process or user
Inspector: The process that we created to monitor the folder.
Inpector sees a change in the folder. Queries with Suspect A whether he did any change to it.
if so,
change is taken as VALID.
if not
clear indication that change is done by *Suspect X*. So NOT VALID!
File is certified to be TAMPERED.
Other than that, below are some of the techniques that may (or may not :)) help you!
Store the time stamp whenever an application close the file along with file-size.
The next time you open the file, check for the last modified time of the time and its size. If both are same, then it means file remains not tampered.
Change the file privilege to read-only after you write logs into it. In some program or someone want to tamper it, they attempt to change the read-only property. This action changes the date/time modified for a file.
Write to your log file only encrypted data. If someone tampers it, when we decrypt the data, we may find some text not decrypted properly.
Using compress and un-compress mechanism (compress may help you to protect the file using a password)
Each way may have its own pros and cons. Strength the logic based on your need. You can even try the combination of the techniques proposed.