Fog Creek Software
Discussion Board




file access restriction


Hi,


I have a quick question.  Is there a way to stop all access to a file?

For example, if I try to copy, delete, rename, etc. the following file:

C:\WINNT\system32\config\system.LOG

I get the message telling me that there has been a sharing violation. I cannot even view the contents of that file using any viewing tool.

Is this just a side effect of having the file open by an application (I guess the OS in this case) which renders all access to the file impossible? Or is it some other special trick?

Thanks!

entell
Tuesday, April 13, 2004

If the file system is NTFS you can set security attributes in such a way that nobody can delete the file.

In the case of SYSTEM.LOG it's almost certainly because the file is pinned down by an open process.

Joel Spolsky
Fog Creek Software
Tuesday, April 13, 2004

The CACLS command will let you do that sort of thing. You can restrict access to a certain user. May be able to restrict it even further.

See cacls.exe /? for more info
Or search the msn.

Naturally, this is only (I think) for NTFS-formatted Windows drives.

Mr. Analogy
Tuesday, April 13, 2004

When you open a file, you usually get to specify what kind of access you want on it (just read?  just write?  both?) and what kind of access you will allow others to perform while you have it open.  (r, w, r/w, none - this is usually called "sharing semantics")

For something like the swap file, the OS doesn't want to give anybody else read/write access to the file, so it opens it in exclusive mode.

That's probably what is going on with your file.  As for finding out which process opened it in that mode, you can try filemon (Google is your friend), but if it was opened on boot-up (say by a service), you may not get the chance to find out.

As mentionned previously, if you use an operating system that supports file security, then that works on top of or under the sharing semantics I just yapped about.

Oli
Tuesday, April 13, 2004


I was hoping to use this feature for security purposes. What I want to do is exactly what the swap files does: namely not allow any process or any user to be able to do anything with the file while I keep the file open.

It seems like it would work nicely for encrypted files. While I decrypt the encrypted file to a temp file, I wouldn't allow anyone to access to the temp file so that the contents aren't comprimised.

Is "sharing semantics" OS dependent? For example when using fopen(), you only specify a mode for how you want to open the file. There are no arguments that I know of to specify the sharing permissions while the file is open. Is there a special API to accomplish this?

entell
Wednesday, April 14, 2004

Entell,

what is the attack scenario you are trying to protect against?

Just me (Sir to you)
Wednesday, April 14, 2004

> Is "sharing semantics" OS dependent?

Yes.

> Is there a special API to accomplish this?

The MS C run-time library has a function named "_open" that lets you specify what sharing you want to permit (perhaps sharing is disabled by default); or the Win32 API has a function called "CreateFile".

Christopher Wells
Wednesday, April 14, 2004

Here's a better idea:  don't decrypt to a temporary file.

You didn't provide the context in which this would be done, but if the user is going to be using the decrypted file after you're done decrypting it, then it does not need to be locked.

On the other hand, if the user isn't supposed to seeing the decrypted data, don't give them any chance to.  i.e. suppose I reset or power down my machine right after your program has decrypted the file to disk.  I can then open it with my favorite editor on the next boot-up.

There's a third option to use something called "protected storage" (or whatever it is called) but that's only on the business line of Windows, IIRC.

Oli
Wednesday, April 14, 2004

Entell,

sharing mode is not a security feature, it is a concurrency control feature. Don't try to abuse stuff. It will not work.
This is a general principle that is very important. Especially in security, do not rely on "hacks". Work with the system, not against it.

A good description on this specific case can be found in this blog entry http://blogs.msdn.com/brian_dewey/archive/2004/01/20/60902.aspx

" "I don't need a strong ACL on my file, because I open an exclusive-access handle to the file."

When you create a file handle using CreateFile( ), you get to specify a sharing mode. This tells the operating system to place constraints on the types of handles that may be opened concurrently with yours. For example, you may choose not to share access with other read handles.

However, the sharing mode is a coarse-grained mechanism for concurrency control; it is not a mechanism to secure access to data. Using sharing modes for security has three problems. First, the proliferation of shadow copy technology within Windows means that, while you may be able to use sharing modes to keep people from reading the current version of a file, there is a high likelihood that there is a read-only copy of the file that is unprotected by sharing modes. Second, there is an inherent race condition when you try to use sharing modes for security: what if the attacker is able to open his handle before you? Finally, if you ever close your handle — for example, if your application AVs — then the data is unprotected."

I am not trying to be pedantic here, but from your posts you seem way out of your depth on this subject (hey, I am too, as I think most of us here).
First think really hard on what you are trying to protect from whom. Diving straight into code libraries is about the worst thing imaginable.

Just me (Sir to you)
Wednesday, April 14, 2004

Well, I am trying to implement encrypted modules. I don't want to rely on NTFS or EFS for security simply because I cannot count on the fact that whoever is going to use these modules will have these features installed/enabled on their Windows.

I thought one way would be to decrypt the encrypted module to a temp file which I lock down using the
CreateFile() function. Obviously this is no good if the power is lost. Then the temp file will be laying there when the user restarts the PC.

So this means I have to do it all in memory instead of using a temp file. Obviously someone can sniff the memory and get to the decrypted content that way. I am not sure if there are any ways around this though.

Seeing past the "sniffing" issue, how do I decrypt a file into memory and still pretend that it is a file? I mean fopen() expects a file with a path and everything. I cannot pass it a pointer to a file in memory, can I? I need something like "ramdisk".

I know security is hard to implement correctly and I don't claim I know everything or anything at all. However, I have to start from some place, and this is my starting point.

I have another thread on the other forum talking about merging cryptography with practical programming. I couldn't find any books that merge the two. Cryptography books only deal with how you encrypt/decrypt your files, but that's not even half the problem.  Security related books talk about network security, how to avoid buffer overflow bugs, etc...

If you know of any tutorials/books which talk about writing programs which are data security conscious, I am all ears.

entell
Wednesday, April 14, 2004

Here is a sample application with explanation http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncapi/html/msdn_cryptapi.asp?frame=true but I still believe you should be very clear about what you are trying to protect against. What powers do you assume your attacker will have? Some things, like a rogue admin with enough knowledge, can not be defended against. You seem to assume things like access to your process memory is compromized. In that case ...

Just me (Sir to you)
Wednesday, April 14, 2004

"Well, I am trying to implement encrypted modules."

In what sense?  In the sense that you encrypt a DLL that represents functionality your base application does not require (but supports) and which can be "unlocked" if the user has a key?

If you are using .NET, then this is [fairly] trivial:  you can encrypt/decrypt to memory or streams and you can load assemblies from memory or streams.  It only gets a little weird when you're dealing with trusting assemblies.  IIRC, Java has something similar.

If you are doing this in plain C (which I am assuming from your mentionning of fopen and the necessity for this to work across platforms) then it can get much messier.  I know Windows can load DLLs from files, but it looks like that's all LoadLibrary will do. (there's no mention of LoadLibrary supporting pipes or sockets or whatnot)

Unless a re-useable "module protection framework" is your core product (it doesn't sound like it), you may want to consider using a third-party protection framework and focus on features for your core product.  At the very least, do this last:  People won't buy your product because it has a neat anti-piracy feature.

Oli
Wednesday, April 14, 2004

> "Well, I am trying to implement encrypted modules."
>
> In what sense?  In the sense that you encrypt a DLL that > represents functionality your base application does not
> require (but supports) and which can be "unlocked" if the > user has a key?

Exactly!

> If you are using .NET, then this is [fairly] trivial:  you can > encrypt/decrypt to memory or streams and you can load > assemblies from memory or streams.  It only gets a little
> weird when you're dealing with trusting assemblies. 
> IIRC, Java has something similar.

I am not using .NET.

> If you are doing this in plain C (which I am assuming from
> your mentionning of fopen and the necessity for this to
> work across platforms) then it can get much messier.  I
> know Windows can load DLLs from files, but it looks like
> that's all LoadLibrary will do. (there's no mention of
> LoadLibrary supporting pipes or sockets or whatnot)

I am not using plain C, but I am finding it to be hard to accomplish. As you mentioned, I have to decrypt into memory, and then pass the code to LoadLibrary somehow. Well actually at that point, there really isn't much to load either since the code is already in memory.

> Unless a re-useable "module protection framework" is
> your core product (it doesn't sound like it), you may want > to consider using a third-party protection framework and
> focus on features for your core product. 

Another difficulty is that the program loading the encrypted DLLs needs to know how to decrypt them. Ideally, I would like to use a different key per DLL and ideally each DLL could only be decrypted on one PC. In other words, copying the DLL and the key to another PC should not work. To do this, I would like the decryptor program and the DLLs to be unique in some way so that mixing them would not work, but generating unique binaries is not the greatest solution.

I don't know.. I need to think more about it. I am not sure if using a third party protection program would help me accomplish this in some way. I have never used them or looked into them.

I know I shouldn't waste too much time on this, but I don't want to not have anything either.

entell
Thursday, April 15, 2004

Entell, why not use something a little more standard such as the PGP SDK.  It will teach you a fair amount about C programming... and certainly public-key cryptography.  It deals well with all sorts of security issues (interim file storage as well as in-memory protection from prying eyes).

And last time I checked, it was free for non-commercial use.

* I'm going from memory, so the standard disclaimer applies.

dir at badblue com
Thursday, April 15, 2004

You can generate a "password" by hashing a machine signature and then implement http://www.ietf.org/rfc/rfc2898.txt . This gives you a symmetric encryption key that is tied to the machine.

Just me (Sir to you)
Friday, April 16, 2004

Is that what they did with Diablo?  I know that game had a problem where some folks lost their savegames when they changed the date on their PC.  Forget about it if your system crashed and you needed to move your HD to another system.  Funny part was, they protected the file data so well, they spawned a whole new wave of memory hacking editors and such that made them go trough a LOT more growing pains than if they'd been a bit less secure and not worried quite so much about what was on the user's HDs.

Derf
Monday, April 19, 2004

And if they spend enough time with SoftIce, I suspect that they'll find a way around just about anything.  All you can do is make it annoying or booring enough that the required tallent won't bother trying to hack it.

Derf
Monday, April 19, 2004

*  Recent Topics

*  Fog Creek Home