A simple question. Is it possible to lock a directory under linux ? Actually what I need is that only one application (which I wrote) has an access to a specified directory which is created by this application. So basically it is a cache directory for that app and so-far users have been messing with it. so i wish to prevent this in future.
Is it possible to do this?? and how (language: c++)?
Not possible in standard C++ at all.
Under linux, use setuid permissions on the executable, so it runs in context of its owner. Then you can lock down access permissions for the directory, so it is only accessible to the owner of the executable.
Of course, this doesn't stop users using your program from messing with your cache. You need to design your program so it prevents inappropriate actions by users. And make sure the owner account (which can be set up specifically for your application) does not have more privileges than it needs.
If you trust people who have "root" permission on the system(s) that this is installed on, you can rely on having a special user or group, and use setuid and/or setgid to prevent others from tampering with the file. This does, however, mean that the installer of the software will need to have root permission, so "any" user can't install the software, which in some circumstances may not be a good solution.
The better solution is really to either have a hash of the file stored in the file [plus some constant data or some such, so that the user can't just run sha1 modified-file and get the "right hash"], or encrypt the whole file.
The problem with BOTH of these methods is that you still can't rely on it 100% - someone with enough motivation and resources will figure out what the constant data is, and just calculate that as new hash after modifying the data in your file. And similarly, assuming your application knows how to decrypt the file, the application can be reverse engineered to find the encryption key and encryption method.
So you are fighting a "code war" (pun on cold war) against your "users".
There are commercial solutions available for license management (and that I have been the user of is FlexLM, but there are several others too). This is a little more work, and will probably cost a little bit in license fees, but you will save yourself a whole heap of potential headache if you use a commercial product.
Related
This is a bit of an oddball question, and I've seen nothing similar asked anywhere on the internet.
What I want to do
I want to release the source code of my website. Beyond that, the nature of the website (described below) is such that I not only want to release the source code, but I want users of my website to be able to unequivocally verify that they're using the exact version of the website as is in the source code dump.
The part that makes it tough is that my good will cannot be trusted. (Obviously, it can since I'm going to this length, but from the user's perspective it cannot).
My (mental exercises) to try to fix this
Attempt 1
So, the first thing I thought about was hashing the source code, or even hashing the entire docker container it's running in, and providing an endpoint that broadcasts that hash, so that it may be matched up against the public source code.
Attempt 2
The second thing I thought about was providing users with a read-only shell login so that they would be able to hash the docker image that's being run. The problem here is, there's no way to verify that the docker image is what is running (to my knowlege). I could just build an image of the public source code and put it there for users to hash.
Also, because of the security concern, I really hate the idea of putting users that close to production.
Attempt 3
Finally, I wondered if it would solve the problem if I used some type of blockchain technology, like a distributed app. But that's so complex, and I don't think it provides extra trust.
Why I want to do this
I am building a website that will be handling incredibly personal data. It could destroy people's lives if any of it was leaked (and no, the TLD isn't .xxx or anything like that. In fact, nothing illegal is going on with this data). However, there is an intense social stigma associated with the type of data, and it actually is enough evidence (in some countries) to peruse the death penalty against a user, if any data is leaked.
So, in addition to having a very explicit (and secure) Privacy Policy, I want to make an open source promise to my users, so that problems can be hunted down by volunteers and quickly eliminated. Also so that they're able to verify that I'm not adding code into the running production version to enable extra spying on them.
Is this type of thing theoretically possible?
As long as the server receives some of this incredibly personal user data in a format that it/you can read it, there is no perfect way. You would have to let the users encrypt the data before uploading it, with a key only they know.
If there is no data transfer involved, then the users can check the code in the browser and compare hashes manually. Perhaps there is an automatic way of doing this. Anyway all work on the data then has to be performed on the client side.
The core problem is that a user has to trust the complete environment, from source code over compiler to executing OS and hardware.
You cannot cryptographically ensure that you do not for example intercept the running program on a low layer and read out data there, even if you had a possibility to ensure that you run the exact code on the server.
"Trust", you can build by legalities and Privacy Policies.
We all willingly keep our sensitive data online in many applications/systems and we never check to see if the source code or the architecture of the system is the same as what they promised at the beginning.
As #tystackoverflow said, building a backdoor in the code is not the only way you can ensure the users of a system that their data is not accessible to anyone else. In this case your system architecture should also support encryption of data at higher level that no one (unless accessed through the system) can have direct access to it.
I do understand the risk of these data leaking,
It all depends on how you design the System to be tamper proof and secure, and conveying the idea behind the security measures you have built in to the Application to its users.
Good Luck with the Project !
I'm creating a C++ linux application that needs some initial parameters of configuration to work correctly, these externals configurations is needed to avoid multiple compilations for parameters changes, and this configurations needs to be unknow by the end users. I was thinking an way do make an hidden configuration file that is consumed at the first execution, and always is researched at execution to verify possibles changes. Some suggestion to do this?
It is unlikely that you can hide the configuration file so that people do not know its existence: most Linux users would want to know which files you are installing in which location, and there are many ways to help them in discovering that, even if you try to do it without telling them (the simplest way that comes to my mind, they may do a file system snapshot and compare it before and after running the install program)
If your goal is to prevent people from changing the configuration without your permission (i.e., without paying for a license upgrade), you may do it by requiring the configuration to be signed from your company, storing the verification key inside the executable.
If you want to prevent the configuration from being read you don't have that much luck: there is not much that can stop a motivated attacker from reading the content of that file, since your application must be able to do it as well.
I've been looking into centralising my computer game saves to make it easier to backup and restore as well as putting them up on the cloud via dropbox but there in so may places that it makes it quite difficult. I noticed the Windows 7 and Vista now support Symbolic links so I've been playing around with that but I was wonder the follow:
Is it possible (code example or a point in the right direction) for an application (vb.net or C++) to spoof a file or folder?
E.g. Application A (a game like Diablo III or Civilization V) attempts to read or right from file A (the game save), application B (the save repository) detects this read/write request and pipes the request through itself preforming the request on file B (the actual game save in another location). Application A is in no way altered and treats the file normally.
Note: I realise there are many simple ways of preforming the same task in essence such as monitoring the use of Application A or periodically checking file A and copying it if it has been altered since the last check etc but all these methods have draw backs and less interested in making it work than if it is possible.
It is entirely possible to do this through a file system filter driver. For information about these, take a look here:
http://msdn.microsoft.com/en-us/windows/hardware/gg462968
Filter drivers can hook into CreateFile operations and redirect the create to a different place if you want, but they are much harder to write as compared to normal applications. They run in kernel mode and must obey the limitations of drivers.
You can "fake" special folders, like control panel does, but I don't think you can create anything accessible/writeable (in an easy way). I might be wrong though. I had the same idea once too (as a compatibility step for some company stuff), but couldn't find anything supporting an easy way to do it. It seems like it might be easier to be done on Unix systems (but that's obviously no option here). Also, I wouldn't expect any nice or easy solutions for .net.
Only approach I could think about right now, would be highjacking the according API calls (e.g. FileOpen) to reroute/manipipulate them (similar to what root kits do), but I wouldn't say that's a good idea, considering it might be detected as possible malware or cheats by things like punkbuster or antivirus solutions.
Yes or no depending on (using your terms) the level of abstraction that Application A is using.
If Application A is performing a CreateFile wto start access and passing a fixed filesystem path then Application B would need to emulate a file system and do so in the kernel.
On the other hand if Application A were to user HTTP with RESTful URLs then the HTTP server could answer all requests from files or by dynamically creating the content.
So the question can only be answered in specific by knowing the details of Application A.
I develop in C++/MFC and have placed all the resources in a separate DLL.
I have seen cases where the resource DLL is modified and the product is sold illegally with different name, graphics etc.
How do I prevent the resource DLL from being modified/hacked?
Sign it and then check thef signature is valid and there. I would use some sort of official certificate for the company but a self-signed will do.
A quick google turned up:
Digital Code Signing Step-by-Step Guide (altho it looks like it's for Office XP)
Prevent DLL Tampering on Windows Apps
UPDATE:
It also pays to sign the EXE as well.
As pointed out in the comment, there is no way you can stop someone with enough skill from tampering with your application. It's all about risk management. How much to you want to 'risk' someone tampering with your application. Is it worth the time and effort to rise the bar so that you need a more highly skilled person to temper with your application? That's up to you.
I would at least sign all your code files that you release anyway. It verifies that those files come from you and have not been tampered with.
If you trust your app you could just calculate a hash on your resource dll before shipping and reject dll:s with other hashes.
You can't. Such issues have to be dealt with through the law, not code. Also note any such "solution" would likely violate user's fair use rights. I have often played around with modifying program resources for fun (e.g. putting a Tux on the Windows login page). I wasn't out to deceive anyone and didn't even distribute the result.
You could checksum the dll binary, check it from the main program and quit / disable features if it's different. It won't stop someone hell bent on ripping off your stuff since they could hack out the checking code in your exe but at least it won't be so easy.
As everyone is saying you can only raise the bar to make it more difficult to hack, I wouldn't spend more time on it than having a hash as disown suggests. An alternate way of thinking about this (if you software allows it) is to make your software attractive in the long term with updates etc. That way people will want an account with you rather than a hacked version.
You can't prevent your application from being hacked any more than you can't prevent your car from being stolen, sure, you can have state of the art alarm system and have it blow fire if it detects it's not the owner, but someone could just break the glass or wear fire-proof suit. In short, you can't.
If this is commercial software and you are worried about theft then you should look at third party solutions. There is plenty of software designed to protect from shareware up. They are different prices with different features.
As others have said no pure software solution is completely safe. But I would recommend outsourcing this and concentrate on the business value your application provides.
You could zip it with an encrypted password and unzip it into a temporary location before reloading it. Something like
BOOL CMyApp::InitInstance()
{
CString TempName = TempFileName();
Unzip("MyZippedResources.Zip",TempName,Password);
HINSTANCE hInst = LoadLibrary(TempName);
}
There are a number of free zip libraries that can cover the unzipping and password protection abovw
Our win32 applications (written in C++) have been around for over 10 years, and haven't been updated to follow "good practices" in terms of where they keep files. The application defaults to installing in the "C:\AppName" folder, and keeps application-generated files, configuration files, downloaded files, and saved user documents in subfolders of that folder.
Presumably, it's "best practices" to default to installing under "c:\Program Files\AppName" nowadays. But if we do that, where should we keep the rest of our files? Starting from Vista, writing to the program files folder is problematic, and there seem to be a million other places that you can put different files, and I'm confused.
Is there a reference somewhere for what goes where?
Edit: To expand on questions people have asked so far:
I'm familiar with the SHGetFolderPath function, but there are lots and lots of options that you can get from it, and I can't find a resource that says "Here is exactly what each of these options is used for, and when you might want to use it".
Up until now, we've done the "All files, including saved user files, under one folder" thing, and it's worked fine - but not when people want to install the app under the Program Files folder. For some reason, the virtualization monkeying around that Vista does isn't working for our application; if we're going to be making changes anyway, we might as well make an effort to do things the "right" way, since we don't want to have to change it again in 12 months time.
Further question:
We include some "sample" documents with our app, which we update every now and again. Is it appropriate to install them into My Documents, if we'll be overwriting them every few months? Or is My Documents assumed to be totally safe for users to mess around in?
If we can't install them to My Documents, where should we put them so that users can see them easily?
Presumably, it's "best practices" to default to installing under "c:\Program Files\AppName"
Close, but not quite. Users can configure the name of the Program Files folder and may not even have a C: drive. Instead, install to the %ProgramFiles%\AppName environment variable folder.
Note you should assume you only have read access to this folder after the installation has finished. For program data files where you might need write access, use %AppData%\AppName.
Finally, are you sure yours is the only app with that name? If you're not 100% certain of that, you might want to include your company name in there as well.
The mechanisms you use to retrieve those variables will vary depending on your programming platform. It normally comes down to the SHGetFolderPath() Win32 method in the end, but different platforms like Java or .Net may provide simpler abstractions as well.
Some guidelines are in this Knowledge Base article: How to write a Windows XP Application that stores user and application data in the correct location by using Visual C++. Also, if you search MSDN for Windows Logo Program you will find documentation regarding what an app needs to do to be truly compliant.
SHGetKnownFolderPath can get you the directories you need. If backwards compatibility with XP and earlier is required, use the deprecated SHGetFolderPath
Having said that, if you app came with documentation that said "everything used by this app is in this directory" I would love it ;)
Use the Windows SHGetFolderPath() function to get the correct directories.
Edit: To reply to your other question, added in the edit: Where to put the sample files of your application does very much depend on whether your application is installed for a single user or for all users, and whether the person installing the application can be assumed to be the one who uses it.
If your program is to be used by multiple users on a system, copying stuff into "My Documents" is not going to work - the files would be accessible only for the user installing the application. Worse, if the only user of your application needed to install as Administrator, then [s]he will not have access to the files either. So unless you are fairly certain that there is only one user for your application, and they have sufficient permissions to install the application using their own account, don't use "My Documents".
IMO you should install sample files into the directory identified by CSIDL_COMMON_APPDATA. This will give you exactly one copy for all users, and since you want every user to see the original, unaltered sample files all users should consider them read-only. In fact, your setup program should probably make them read-only. Opening one of the samples will work for all users, but as soon as they try to save their modifications the application should detect that the file is read-only, and open the "Save As" dialog, pointing to "My Documents" or suitable directory inside. That will also keep all user modifications when the installer updates the sample files later on.
It is of course somewhat more difficult for the users to find the sample files. You could add a link to the samples folder to the start menu group of your application, so that access to the files is fast, and of course you should properly document everything.
For your application binaries, you can assume that you may write to the PROGRAM FILES directory (use the %ProgramFiles% environment variable to support installations other than the default English version - e.g. in german Installations this will be c:\Programme by default). Wikipedia lists the most common variables. Another option are the SHGetFolderPath or newer SHGetKnownFolderPath functions.
For User data, you should assume that the application is running with limited access rights and may only write to the user's home directory. Same applies for registry entries. This path should probably be configurable b the user, as the home directory may actually be a network server and a user might have a second disk attached for data storage. For information on the current (Vista) filesystem guidelines see this article.
Regarding plugins, this might be more complicated. The best practice seams to be offering the option to install for the current user only, and placing the plugin in the user directory, or install for all users and place the files into your program files directory (but remember to check for write permission and request elavated access if needed).
There are plenty of environment variables like: %USERPROFILE%, %HOMEPATH%, %APPDATA% all of these points to some user-specific directories, where you can put your user-specific files.
For system-wide storage you can use %ALLUSERSPROFILE%, that is the place where you should put your read/write datafiles that are not specific to any user.
Sorry I don't know the correct answer, but...
Do you have a business case for wanting to do that? Are your customers complaining that files aren't stored where they expect? Are your applications crippled in some way because you store files in non-standard locations? If not, I don't see a reason for spending time and budget to redo your file storage strategy just to meet "best" practice. If your programs just work, then IMHO you should leave them alone and spend money and time on things that matter.
There is a directory structure under c:\users for user oriented data.
There is documentation for porting apps from older windows OSs to Vista.
Check out http://www.innovateon.com and follow the links to Vista. There is documentation regarding certification that has the details on topics like this.
We have a similar app created ~10 years ago using MFC. The easiest thing to do was create a folder right off of C:\ (e.g. C:\OurApp). No install files, no special permissions, no registry changes, etc. Clients (and particularly their sys admins) LOVE it.
One other consideration - are you planning to all of a sudden change the installation folder for existing clients (assuming this is installed in many locations)? If something isn't broke, why fix it?