Safety programming: avoid competitive conditions
content:
Competitive Conditions Introduction Solving Competitive Conditions Lock Files Continued File System Sharing Directory (such as / TMP) Sharing Directory Basic Concept Shared Directory Signal Signal Processing Conclusion Reference About the author to this paper
related information:
Security Programming: Developing Security Program Server Clinics: Practical Linux Security Software Security Principles: Part 1 Building Security Software: Select Technology, Part 1
subscription:
DeveloperWorks News DeveloperWorks Subscribe (Subscribe CD and Download)
Resource contention may be unfavorable to you
Level: Intermediate
David A. Wheeler
(Dwheeler.com@dwheler.com) Full-time researcher, INSTITUTE for Defense Analysis 2004 October 25
Understand what is competitive, and why they will trigger security issues. This article shows you how to handle common competitive conditions in the Unix-Like system, including how to create an alternative to lock files, lock files, how to handle file systems, and how to handle shared directories (especially How to create a temporary directory correctly in the / TMP directory). Need you to know the signal processing.
Through a stealing password, Mallory successfully logs in to an important server running Linux. Its account is a very limited account, but Mallory knows how to use it to create trouble. Mallory installed and running a very strange applet, which uses multiple processes to quickly create and delete many different symbolic link files in the / TMP directory. (The symbolic link file is also known as SymLink, is a simple file. When it is accessed, it will redirect the request to another file.) Mallory's program constantly creates and deletes many points to the same special file (/ ETC Different symbolic link files for / passwd, password files. One of the security measures of this important server is that it runs Tripwire every day - specifically, it is an older version 2.3.0. TripWire is a security program that detects whether important files are tampered. Like a lot of programs, TripWire will try to create a temporary file. TripWire will view and determine that there is no file called "/ TMP / Twtempa19212", so it looks like a suitable temporary file name. But after TripWire completes the check, Mallory's program will create a symbolic link file using this name. This is not accidental; the design objective of the mallory program is to create the file name most likely to be TripWire. Then TripWire opens the file and start writing temporary information, but does not have to create a new empty file, TripWire is now overwriting the password file! Since then, anyone- or even administrators - cannot log in to the system because the password file has been destroyed. Worse, Mallory's attack can override all files, including important data stored on the server. Introduction to Competitive Conditions This is an imaginary story; "mallory" is a usual name of the attacker. But this type of attack, and the defects it use is extremely common. The problem is that many programs are easily influenced by security issues called "Competitive Conditions". When the competition for the same resource is caused due to an abnormal event order, "Competitive Conditions" will occur when the program cannot operate normally. Note that competition conditions do not need to intervene in competition between the two parts of the same program; if an external attacker can interfere with the program, there will be many security issues. For example, if TripWire 2.3.0 determines that a file does not exist, it will try to create the file without considering whether the file is created by the attacker during the two steps. Decadary ago, the competitive conditions were still not a problem; at that time, the computer system usually only runs a separate program at the same time, and you can't interrupt it or compete with it. However, today's computers typically need to run a lot of processes and threads at the same time, and there are often multiple processors that do different programs simultaneously. This is more flexible, but there is a danger: if these processes and threads share all resources, they may affect each other. In fact, competitive conditions defects are one of the more common defects of software. In addition, / TMP and / VAR / TMP directory are often incorrectly used in the class UNIX system, resulting in competitive conditions. However, we first need to know some terms. All class-Uix systems support user processes; each process has its own memory space (other processes are usually unacceptable). The underlying core will try to make the process look like running at the same time; in the multiprocessor system, they can actually run simultaneously. In theory, a process can have one or more threads; these threads can share memory. Threads can also be run at the same time.
Since the thread can share memory, it is more likely to produce competitive conditions relative to the process; for this reason, the debugging of multi-threaded programs should be more difficult. Linux kernel has a very good basic design: only threads, and some threads can share memory with other threads (this implementing traditional threads), while others cannot (this implementation independent process). In order to understand the competitive conditions, let us first look at a very ordinary C declaration: list 1. Ordinary C declaration B = B 1;
It looks very simple, isn't it? However, let us assume that there are two threads running this line of code, here, "B" is a variable shared by two threads, "B" initial value is "5". The following is a similar, not, execution order: Listing 2. Possible execution of shared "B"
(Thread1) Load B Into Some Register in Thread1.
(Thread2) Load B Into Some Register in Thread 2.
(Thread1) Add 1 to Thread 1's Register, Computing 6.
(Thread2) Add 1 To Thread 2's Register, Computing 6.
(Thread1) Store The Register Value (6) To b.
(Thread2) Store The Register Value (6) To b.
The initial value is 5, and then the two threads add 1, but the final result is 6 ... instead of 7. The problem is that the two threads interfere with each other, causing the final answer to the error. Typically, the thread is not performed in a matter of atom; another thread can interrupt it during any two instructions, and some shared resources can also be used. If the thread of a security program does not prevent these interrupts, then another thread can interfere with the thread of the security program. In the security program, the program must run correctly in the middle of how much other threads run in any pair of instructions. The key is that when your program accesses any resource, make sure that other threads may cause interference because of the use of this resource. A typical solution to solving competitive conditions competitive conditions is to ensure that the program has its own proprietary power when using a resource (such as files, devices, objects, or variables). The process of obtaining a proprietary right to a resource is called lock. The lock is not easy to handle. Dead lock ("Hug, Deadly Embrace") is a common problem. In this case, the program will not continue to run due to the release of the locked resource waiting for the other party. All threads must be locked in the same order (for example, in order of alpha, or from "Largest Grain" to the order of "smallest grain", this can avoid most of the deadlocks. Another common problem is a Livelock. In this case, the program has successfully obtained and releases a lock, but the program cannot continue to run again in this way. If a lock is hang, it will be difficult to release it smoothly. In short, compiling can be often difficult to lock and release procedures that need to be properly locked and released. Sometimes, a single operation can be performed at a time, so that some special operations can be completed, so that you don't need to explicitly lock a resource and then unlock. Such an operation is called "atom" operation, as long as you can use this type of operation, they are usually the best solution. Some errors are so common, so in order to avoid these mistakes, you need to know them. One problem is to create a lock file in a way that is not always locked; you should learn how to create them correctly, or turn different lock mechanisms. You also need to handle competition in the file system, including how to handle shared directories / TMP and / var / tmp, and how to securely use signals. How to use them safely in the next chapter. Lock files typically, the class UNIX system is to achieve locks between different processes by creating files representing a lock. Use a separate file to represent the lock, an example of "Advisory" lock instead of "mandatory" lock. In other words, the operating system does not force you to share resources by locking, so all processes that need this resource must use this lock. This seems to be very simple, but not all simple ideas is not a good idea; create a separate file, it can easily obtain the state of the system, including which resources are locked. If you use this method, some standard skills can simplify these locks, specifically, it is to delete those hangs. For example, a parent process can set a lock, then call a child process to perform the job (make sure the parent process can effectively call the child process, when the child process returns, the parent process releases the lock.
Alternatively, you can use the cron job to see those locks (which include process IDs); if the process is not active, the job will clear those locks and restart the corresponding process. Finally, the clearance of the lock file can be used as part of the system start (so that your lock is no longer in the system after the system suddenly crashes). If you are creating a separate file to indicate the lock, you should pay attention to a common error: Creat () or the call of the Open () is called (mode is O_Wronly | O_CREAT | O_TRUNC). The problem is that root can always create files, even if the lock file already exists, this means that the lock cannot work normally for root. A simple solution is to specify tag o_wronly | o_creat | o_excl (set permissions to 0, making the lock). Note that O_EXCL is used, which is a formal way to create a "dedicated" file; even on the local file system, root can also do this. This simple method is not applicable to NFS version 1 or version 2; if you must use a lock file on a remote system connected to these old NFS versions, you can use the solution given in the Linux document: "On the same file system Create a unique file (for example, with host name and PID), use link (2) to create a link to the lock file, use stat (2) to check if the unique file's link counter is added 2. Do not use LINK 2) The return value called. "If you use a file to indicate the lock, you must ensure that these lock files are placed in an attacker (for example, where they cannot delete them or add files that interfere with their files). A typical solution is to use a directory that allows the permissions of the directory not to add or delete files unauthorized. Make sure that only the programs you can trust can add or delete the lock file! Filesystem Hierarchy Standard, FHS is widely used by Linux systems, and also introduces this type of lock file standard convention. If you just want to make sure your server is running no more than once on a given machine, you should usually create a process identifier named /var/run/name.pid, with process ID as a file content. According to the same idea, you should place the lock files such as the device lock file in / var / lock. The replacement of the lock file uses a separate file to indicate the lock is a very old way. Another method is to use the POSIX record lock (Record Locks), which is implemented as an arbitrary lock via FCNTL (2). There are many reasons for using POSIX records: POSIX record locks have been supported on almost all class UNIX platforms (it gets the authorization of POSIX.1), which can lock part of the file (instead of only locking the entire file) And it can distinguish between the difference between the read lock and the write lock. Also, if a process is dead, its POSIX record lock will be automatically deleted. Only when all programs work together, use separate files or FCNTL (2) to take effect. If you don't like this idea, you can turn to use the SYSTEM V style forced lock.
Forced lock allows you to lock a file (or part of it), enabling each read (2) and write (2) check the lock, any operation without this lock will be suspended until the lock is released . This may be slightly convenient, but there is also a shortcoming; the process with root privileges may also be forced to hang, which is often easily attacked by Denial-of-service In fact, the rejection service problem is very serious, so it is usually avoided using a forced lock. Forced lock is wide range, but it is not common; Linux and System V-based systems support this lock, but other class Unix systems do not support it. On Linux, in order to enable forced file lock, you must assemble file systems in a specific way, so many configurations do not support forced file locks by default. Inside the process, threads may also need locks; there are many books discussed these issues very detailed. Here, the main problem we want to discuss is to ensure that you can't care about all situations; it is easy to forget a particular situation or have not properly processed. In fact, it is difficult to use the lock correctly, and an attacker may use the errors in these lock processing. If you need to use a lot of locks to threads within a process, you can consider using the maintenance of the automatic lockover language or language structure. There are many languages, such as Java and ADA95, have a built-in language that automatically handles lock maintenance (and makes a more correct). As long as it is possible, it is best not to use the lock at the time of the development program. A separate server process receives only one client request each time, then processes the request until the request is completed, and then the next request is obtained, in a sense, all objects inside the process are automatically locked; This simple design avoids a lot of dangerous locking problems. If you need a lock, keep its simplicity (such as using the only lock for almost everything) is good. This is not always practical because this design sometimes harm the performance. Specifically, the single server system needs to ensure that no matter which operation is not occupied. But this suggestion is worth considering; the system using a lot of locks will be more likely to be defective, and these locks will also affect performance. The writing of the file system security program must ensure that the attacker cannot use the shared resources in a way that causes the problem, sometimes it is easy to do as it looks like it. File system is one of the most common shared resources. All programs can share a file system, so there is sometimes additional efforts to ensure that an attacker cannot utilize a file system in a trigger. There are a lot of programs that are determined to be safe, are called "Time of Check - Time of Use" (TOCTOU) competitive conditional defects. This only shows that the program checks if some situation is feasible, then use that information later, but an attacker may change the situation between the two steps. For document systems, the following problems are particularly highlighted; between these two steps, attackers can usually create a normal file or a symbolic link. For example, if a privileged program checks if there is no given name file, then open the file write information, between the two steps, the attacker can create a symbolic link file using the name. .. such as / etc / passwd or some other sensitive files. Obey some simple rules can avoid these issues:
Don't use Access (2) to determine if you can do something; usual attacker will change the situation after calling Access (2), so any data obtained by calling Access (2) may no longer be trustworthy of. For a way, set the privilege of your program is just the privilege you want (for example, set its valid ID, file system ID, or valid GID, and clear all unwanted groups via setGroups); then call Open (2) opens or creates the files you need. On the class UNIX system, the Open (2) call is atom (different from the previous NFS version 1 and version 2). When you create a new file, open it with o_creat | o_excl mode (make sure that the O_EXCL will be called only when you create a new file). Originally only grant with very limited permissions; at least any user is prohibited from modifying it! Usually, this means that you need to use umask and / or open parameters, limit the initial access rights to the user, or may be limited to the group where the user is located. Don't try to reduce permissions after you create a file, because this will lead to competitive conditions. On most class UNIX systems, only check permissions when the file is opened, so an attacker can open the file when permission bit is allowed, and the file has been in an open state, regardless of how the authority changes. If you are willing, you can also modify your permissions more open. You also need to prepare for open failure. If you absolutely need to open a new file, you should create a loop: (1) Creating a "random" file name, (2) Use the o_creat | o_excl option to open the file, (3) Stop loop after successfully open the file. When operating the meta information of the file (such as modifying the owner, statistics on the file, or modify its permission bit), first turn on the file, then operate the open file. As long as it is possible, try to avoid the operation of obtaining the file name, but use the operation of the acquisition file descriptor. This means to use FChown (), fstat () or FCHMOD () system call, without using a function of the file name, such as Chown (), chGRP (), and chmod (). This will avoid files to be replaced when your program is running (a possible competitive condition). For example, if you close a file, then use chmod () to modify its permissions, then attackers are likely to move or delete the file between these two steps, and create a point to another file (such as / etc / passwd). Symbolic link. If your program needs to traverse the file system (recursively traversal subdirectory), then the attacker may take advantage of the directory structure you are traversing. A common example of this situation is that the administrator, system program, or privileged server running your program is traversing the file system part of the ordinary user control. The GNU File Utility (FileUtils) can complete the recursive directory deletion and directory movement, but before version 4.1, when it traverses the catalog structure, it is just a simple follow ".." this special entry. When the file is deleted, the attacker can move a low level directory to a higher level; FileUtils will follow ".." directory up to higher level, may keep the root of the file system. By deleting a directory at an appropriate time, an attacker can delete any files in your computer.
You should not trust ".." or "." If they are controlled by the attacker. If possible, do not place the file in the directory that can be shared by the untrusted user. If not that, you should try not to use the directory between users. Don't mind create a directory that can only be accessed by trusted specific processes. Consider avoiding using traditional shared directories / TMP and / VAR / TMP. If you can use only one pipe, send the data from a location to another, then you can simplify the program and exclude potential security issues. If you really need to create a temporary file, you can consider storing temporary files to elsewhere. If you are not writing a privileged program, this particularly needs to be considered; if your program is not privileged, place the temporary file in the user directory will be more secure (to handle the root user, it "/ "As its home directory). In this way, even if you don't "correct" create temporary files, attackers usually cannot cause problems (because attackers cannot utilize the contents of the user's home directory). However, it is not possible to avoid using a shared directory, so we need to understand how to handle / TMP and other shared directories. This is very complicated, so it should take up a section! Share Directory (such as / TMP) Shared Directory Basic Concept If your trusted programs will share a directory with potential non-trust users, then be careful. In the class UNIX system, the most common shared directory is / TMP and / VAR / TMP, which breeds a lot of security defects for these directories. Originally created / TMP directory, which is a convenient location that creates temporary files, usually should not share temporary files with anyone else. However, this directory has a second use - Create a standard location of the user shared object. Since there are a variety of uses in these standard catalogs, it is difficult for operating systems to enhance access control to prevent attacks; therefore, you must use them correctly to avoid attacks. When you use a shared directory, make sure that the directory and file have appropriate permissions. Obviously, you need to limit which people can read and write files created in the shared directory. However, in the class UNIX system, if multiple users can add files to the same directory, and you plan to add files to the directory through a privileged program, then make sure to set the "Sticky" bit for the directory. In an ordinary directory (no sticky bit), anyone has a write permission - including an attacker - can delete or rename a file, resulting in a variety of issues. For example, a trusted program can create a file in such a directory, and an untrusted user can delete or rename it. On the class UNIX system, you need to set the "Sticky" bit of the shared directory; in the Sticky directory, the file can only be linked or rename the owner of the root or file. / TMP and / VAR / TMP directory are usually implemented as a "sticky" directory to exclude some issues. The program sometimes leaves a useless temporary file, so most class UNIX systems automatically delete the original temporary files under specific directory / TMP and / var / TMP ("TMPWATCH" program can complete this task), some The program will "automatically" to delete the files in the specific provisional directory they use. This sounds very convenient ... Unfortunately, an attacker may make the system be particularly busy, so that the activity documents become old files. Result: The system may automatically delete the file name being used. Then what happens? Attackers may try to create files their own identical names, or at least let the system create another process and reuse the same file name. RESULTS: Confusion. Such problems are called "TMPWATCH".
The method of solving this problem is that once a temporary file is automatically created, the file descriptor or file stream obtained when opening the file must always be used. Never reopen the file or use any action as a parameter - Always use the file descriptor or related stream, TMPWATCH competition will lead to some problems. You can't even create a file first, then turn it off, then reopen it, even if the authority has restricted who can open the file. Attack the Sticky directory, and the restricted permissions of the file you created are just the first step. An attacker may try to perform insertion operations during the operating safety procedure. A common attack is that when your program is running, create and reverse creation in a shared directory to create a symbolic link to other files - / etc / passwd or / dev / zero is a common goal. The attacker's goal is to create such a situation, that is, let the security program determine that a given file name does not exist, then the attacker can create a symbolic link to another file, and the post security program continues to perform some Operation (but now, it is actually an expensive file). Important files are often destroyed or changed like this. Another variant of this approach is that the creation and reverse creating an attacker can perform a normal file for writing, so that an attacker sometimes controls the "internal" file created with privileges. When you create a file in these shared directories, a problem that is often met is that you must make sure that the file name you plan is created and does not exist when you create it, and then automatically created. Check if the inspection is not used by "previous", because the file has been created with this file using the file name before the check has been checked but has not created the file. It is useless to use "unpredictable" or "unique" file name, because the attacker can repeatedly guess the name of the file until success. So, you need to perform one or create a new file or failing - don't do anything else. The Unix system can do this, but you need to know how to ask the system to do. What is unfortunate for shared catalogs is that there are many solutions. Some programs just call MkTemp (3) or TMPNAM (3) to create a temporary file, and then make a successful assumption to simply open it. Wrong plan! In fact, threads use TMPNAM (3) is not reliable, and it cannot be reliably handled loop, so don't use it. "Single Unix Specification" in 1997 recommended TMPFILE (3), but unfortunately, it is unsafe to achieve it on some old systems. In C, in order to securely create temporary files in a STICKY directory, the usual solution is to set the umask () value to a very limited value, then do the following: (1) Create a "random "File name, (2) use the o_creat | o_excl option open (2) it (this will automatically create files, if the file is not created, the operation failed), (3) Stop repeating steps when the file is successfully opened. C programmers don't actually do it directly; just call library functions MKSTEMP (3), you can open the file. Some implementations of MKSTEMP (3) do not set umask (2) to a limited value, so smart practice is to call Umask (2) to force the file to set the file to a restricted value. There is a small trouble, MKSTEMP (3) does not directly support TMP or TMPDIR environment variables, so if this is important to you, you have to do more work.
When you create a file system object in a shared (temporary) directory in order to securely open the temporary directory, the GNOME programming wizard recommends you to use the following C code: Listing 3. Recommended c code for creating a temporary file;
Int fd;
Do {
FileName = Tempnam (NULL, "foo");
FD = Open (filename, o_creat | o_excl | o_trunc | o_rdwr, 0600);
Free (filename);
} while (fd == -1);
Note that although an unsafe Tempnam (3) function is used, it is packaged in the loop and uses the O_CREAT and O_EXCL options to offset its security weaknesses, so this is ok. An attached advantage is that TempNam (3) usually uses TMPDIR, which allows users to redirect their temporary files, if needed. Note that you need a Free () file name. After using it, you should close () and unlink () files. This approach has a small disadvantage that various compilers and security scanners may have issued a non-logical warning to you because it may not be safe to use Tempnam. This problem does not exist in using MKSTEMP (3). The entire way to open files shows a strange place for standard C IO libraries: there is no standard method to specify the O_EXCL option to use fopen (), so you can't open the file in "normal" C mode, and safely Create a temporary file. If you want to use the standard C IO library, then use Open (), then you can use FDOpen () specifying the "W B" mode to convert the file descriptor into a file *. Perl programmers should use File :: Temp, which attempts to provide a cross-platform approach to securely create temporary files. However, first, read how to use its document correctly; it also has unsafe function interfaces. I recommend that you explicitly set Safe_level to high; this will call additional security checks. This is the case for most programming libraries; most libraries have both secure interfaces, and unsafe interfaces, so you need to check the document and make sure the secure version is selected. Note that O_EXCL is used in the directory of the old NFS (version 1 or version 2), because the old version of NFS does not correctly support O_EXCL. If you use O_EXCL yourself, and the shared directory is implemented using these old NFS, then your program will be unsafe. In fact, there is a complex solution for LINK (2) and STAT (2) in the old version of NFS; if your program must work in such an environment, then you can in Linux Open (2) man page Or otherwhere reading the contents of this method. Here I am not prepared to discuss it, because even if your program can be used with the old version of NFS, many other programs you use will not use this solution. No matter how you use the provision of the provisional directory using NFS version 1 or version 2, because other programs do not use this solution, if you use the temporary directory of remote mount, a more sensible approach is to use NFS versions. 3 or higher. You can try to use MKDTEMP (3), but this is usually not a good idea because the tempol clearance (Temp Cleaners) may decide to clear them. If you are writing a shell script, you can use a pipe or store the temporary file in the user's home directory. Do not use the / TMP or / VAR / TMP directory; normal shells typically not support file descriptors, so the temporary file cleaner will eventually fail. If there is no temporary file cleaner, and you just have to create temporary files in / tmp, then at least use mkTemp (1) to prevent more obvious attacks, because MkTemp (1) (not MkTemp (3)) will use O_EXCL Prevent typical competitive conditions attack.
The worst thing you may do is usually the most disturbing thing: assume that "$$" is not guess by the attacker, but only redirects the information to such files; then you will use O_EXCL as required when you created mode. Attackers can simply prepare similar files, or create and delete them, and finally take over the program. In this way, similar shell scripts have almost certainly have a serious defect: Listing 4. A defective shell script echo "this is a test"> / TMP / TEST $$ # don't do this.
Don't use the temporary file name again (ie, don't delete and recreate files), no matter how you initially get the "secure" temporary file name. Attackers may observe the original file name and illegally control it when you recreate it for the second time. Of course, always use the right file permissions. Do your own cleanup work, or use the exit processor, or use the UNIX file system semantics, immediately update immediately after you create () this file so that you can still access the file while clearing the directory entry until it point to its last one. The file descriptor is turned off. Thus, you can access the file by sending a file descriptor in your own program. For code maintenance, there is a lot of benefits of losing files: no matter how your program crashes, the file will be automatically deleted. It also reduces the possibility of maintainers insecure using the file name (change to the file descriptor). There is also a small problem immediately released the link, that is, this makes the administrator to see the difficulty of the disk space usage is slightly increased. Make these countermeasures a part of the operating system has achieved some success, although they are currently not widely used. To get more information, see the LINUX kernel patch, Raceguard, and Eugene Tsyrklevich and Bennet Yee's work link in the list of Solar Designer from the OpenWall project. Signal processing also has a competitive condition in the signal. The program can register to handle various types of signals, but the signal may appear in the least appropriate, including when you are processing another signal. One thing you usually do in a signal processor is to set a global tag that will be processed later. There are also several operations that can be done safely in the signal, but not a lot, and you must have an in-depth understanding of it before processing the signal. That is because only some system calls can safely call internal signals: only re-entrant or calls that are not interrupted can be safely called. You can call the library function, but only have a very few functions are securely called; the most of the function calls in a signal processor is the main cause, such as free () or syslog (). For more information, read an article called "Delivering Signals for Fun and Profit" in Michal Zalewski. But it is best to set tags in a signal processor (nothing else), which is overhak to create a complex processor. Conclusion This article discusses what is competitive conditions, and why it will lead to security issues. We have analyzed how to create a lock file and its alternatives. Also studied how to handle the file system and focus on how to handle shared directories to complete some common tasks such as creating temporary files in the / TMP directory. We also briefly study signal processing, at least fully understanding a safety method using them. Of course, it is important to protect your procedure from failure to compete. However, most of the current fewer programs do not complete all things; they must issue a request to other libraries and programs (such as command interprees and SQL servers). One of the most common ways to attack programs is to use these programs to issue a request to other programs. So, then we will analyze how to call other programs while not exposing defects. Reference
You can see this article in our website on our world. Read other security programming column articles on David on developerWorks. David Secure Programming for Linux and UNIX HOWTO (WHEELER, March 2003) Detailed on how to develop secure software. Jarno Huuskonn published Bugtraq Email "Tripwire Tempoorary Files" on July 9, 2001, which gives information about TripWire 1.3.1, 2.2.1 and 2.3.0 Symlink / Competitive conditional issues. This is CVE-2001-0774. CVE-2002-0435 pointed out the competitive conditions in the GNU file utility. Perl 5.8 Documentation of File :: Temp can be obtained online. Kris Kennaway's Posting to Bugtraq About Temporary Files (December 2000) discussed the temporary documentation. Michael Zalewski's Deliver Zalews for Fun and Profit: Understanding, Exploiting and Preventing Signal-Handling Related VulneRabilities (May 2001) describes signal processing, which is another way to introduce competitive conditions. MICHAL ZALEWSKI's problems with mkstemp () discusses security issues from automatic clearance of temporary directory. Security Section of The Gnome Programming Guidelines gives a reasonable advice on how to create temporary files. Single Unix Specification Version 3, 2004, A.K.A. IEEE STD 1003.1, 2004 version is a general description of what must do for the "class UNIX" system. Solar Designer's Linux Kernel Patch from the OpenWall Project introduces some interesting security strategies, including additional access restrictions for prevention of limited set of file system competitive conditional attacks. More specifically, it limits the user's untrusted symbolic link created in some directories and restricts the hard link to files that users get to the file they cannot read. Crispin Cowan, Steve Beattie, Chris Wright and Greg Kroah-Hartman co-author of RaceGuard: Kernel Protection From Temporary File Race Vulnerabilities article 2001 Usenix Security Symposium from Usenix Association, introduces RaceGuard the Linux kernel modifications, it is detected by at runtime Some attacks prevent some competitive conditions attacks. Eugene Tsyrklevich and Bennet Yee Dynamic Detection and Prevention of Race Conditions in File Accesses are from 12th Usenix Security Symposium (August 2003), which describes a method of preventing competitive conditions in a file system. They modified the OpenBSD kernel so that when a file system operation interferes with another operation, it is temporarily suspended, allowing the first process to continue to proceed to the access of a file object.
In the developerWorks Linux zone, you can find more reference materials for Linux developers. Can the developerWorks Speed-start your Linux app can be downloaded from the zone running on Linux, after a free test version carefully selected developerWorks Subscription products, including WebSphere® Studio Application Developer, WebSphere Application Server, DB2® Universal Database , Tivoli® Access Manager and Tivoli Directory Server. If you want to get started more quickly, please refer to how-to articles and technical support for a variety of products. Add to the DeveloperWorks community by participating in the developerWorks Blogs. Linux books that can be purchased in the developer bookstore Linux column. Regarding the author David A. Wheeler is an expert in computer security, he has long been committed to improving the development technology of large and high-risk software systems. He is the author of Secure Programming for Linux and UNIX HOWTO, and is also a verifier of common standard (CommON criteria). David wrote Why Open SourceSoftware / Free Software Look at the Numbers article, and is Ada95 Springer-Verlag publishing:?! Author The Lovelace Tutorial book, In addition, he also published by the IEEE Software Inspection: An Industry Best Practice a The computing of the book and the first editor. This developerWorks article represents the author's point of view, but does not necessarily represent the position of Institute for Defense Analyzes. You can contact David from dwheeler.com@dwheeler.com (deleted "NOSPAM" later).
