temporary directories

[leichter_jerrold at emc.com (Leichter, Jerry)]

[MJoderator:  This is likely beyond the point of general interest to sc-l]

On Fri, 29 Dec 2006, ljknews wrote:

| Date: Fri, 29 Dec 2006 20:49:01 -0500
| From: ljknews <ljknews at mac.com>
| To: sc-l at securecoding.org
| Subject: Re: [SC-L] temporary directories
| 
| At 6:56 PM -0500 12/29/06, Leichter, Jerry wrote:
| 
| > | Not on Unix, but I tend to use temporary names based on the Process ID
| > | that is executing.  And of course file protection prevents malevolent
| > | access.
| > |
| > | But for a temporary file, I will specify a file that is not in any
| > | directory.  I presume there is such a capability in Unix.
| 
| > You presume incorrectly.  You're talking about VMS, where you can
| > open a file by file id. 
| 
| Actually, I was talking about using the FAB$V_TMD bit when creating
| the file.
The way one would get the effect of TMD on Unix is to create the file
normally and, while keeping a descriptor open on it, delete it.  The
file will then "live" and be completely usable to this process or to
any other process that either (a) already has it open (legitimately
or because they snuck in on the race condition); (b) receives the open
dexriptor by inheritance after a fork(); (c) receives the open descriptor
by an explicit pass through a Unix-mode socket (a relatively little
used facility).  However, no one would be able to find the file
through any file system entry, and no user-land code could get to
it through its inode number even if it got its hands on that number.

| > One can argue this both ways, but on the specific matter of safe
| > access to temporary files, VMS code that uses FID access is much
| > easier to get right than Unix code that inherently has to walk
| > through directory trees.  On the other hand, access by file id
| > isn't - or wasn't; it's been years since I used VMS - supported
| > directly by higher-level languages (though I vaguely recall that
| > C had a mechanism for doing it).
| 
| In Ada invoking <packagename>.CREATE with a null name will do the
| trick, although if your VMS experience ended before 1983 you would
| not have run into that.  But how to program easily against VMS V4.1
| when the latest version is VMS V8.3 is not a typical problem.
I think the last VMS version I actively used was 5.4 or so.

| I gather you are saying that the innards of Unix will force creation
| of an unwanted directory entry on the Ada implementation of the required
| null name support for <packagename>.CREATE .  The Ada implementation
| could rely on exclusive access to the file (surely Unix has that, right?)
Not typically, no.  (There are extensions, but standard Unix has only
advisory locking - i.e., locking enforced between processes that
choose to make locking calls.)

| coupled with whatever Unix has that passes for the FAB$V_DLT bit to
| delete the file on Close (such as at <insert Unix words for image rundown>).
There's no direct analogue.  Unix inode's are reference-counted - a
directory entry is a reference.  There's no explicit way to delete a
file - all you can do is get rid of all the references you can.  If
that gets the ref count down to 0, the file will disappear "eventually".
(There's a separate count of open file descriptors to implement that
"sticks around while open" semantics.)

| But these are problems that have been solved by those who provided the
| Ada implementation (ACT and Aonix come to mind for Unix), and thus are
| not an issue for the high level language programmer.
Presumably they do the create-the-file-and-immediately-delete-it trick.
Since the file must, however briefly, have an entry in some directory.
General purpose code can't make assuptions about what directories
are available for writing, so pretty much has to put the entry in
a known, public place - almost always /tmp or /var/tmp.  Unless one
does this very carefully, it's open to various attacks.  (For one
trivial example, there is no way to tell the open() call to *always*
create a new file - you can only tell it "if the file already exists,
don't open it, return an error instead".  The code had better check
for that error and do something appropriate or it can be fooled into
using a file an attacker created and already has access to.)

The techniques for doing this are complex enough - and the attacks
if you don't do it *exactly* right obscure enough - that after all
these years, attacks based on "insecure temporary file creation"
are still reported regularly.  (Frankly, even though I know that
these problems exist, if you were to ask me to write a secure
temporary file creator right now, I wouldn't try - I'd look for
some existing code, because I doubt I'd get it right.)

                                                        -- Jerry

| -- 
| Larry Kilgallen
| _______________________________________________
| Secure Coding mailing list (SC-L) SC-L at securecoding.org
| List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
| List charter available at - http://www.securecoding.org/list/charter.php
| SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
| as a free, non-commercial service to the software security community.
| _______________________________________________
| 
|