Page History

Files should be created with appropriate access permissions. Creating a file with insufficient file insufficiently restrictive access permissions may allow unintended access to program-critical files. File an unprivileged user to access that file. Although access permissions are heavily dependent on the underlying operating system.  This recommendation offers three examples of how to specify access permissions for newly created files using standard C, Win32, and POSIX functions.

...

file system, many file-creation functions provide mechanisms to set (or at least influence) access permissions. When these functions are used to create files, appropriate access permissions should be specified to prevent unintended access.

When setting access permissions, it is important to make sure that an attacker cannot alter them. (See FIO15-C. Ensure that file operations are performed in a secure directory.)

Noncompliant Code Example (fopen())

The fopen() function does not provide a mechanism to allow the programmer to explicitly specify file access permissions. In the this noncompliant code example below, if the call to fopen() creates a new file, the access permissions for that file will be are implementation defined. Note that on POSIX compliant systems the permissions may be influenced by the value of umask().-defined:

char *file_name;
FILE *fp;

/* Initialize file_name */

fp
...
FILE * fptr = fopen(file_name, "w");
if (!fptrfp){
  /* Handle Errorerror */
}

Implementation Details

On POSIX-compliant systems, the permissions may be restricted by the value of the POSIX umask() function [IEEE Std 1003.1:2013].

The operating system modifies the access permissions by computing the intersection of the inverse of the umask and the permissions requested by the process [Viega 2003]. For example, if the variable requested_permissions contained the permissions passed to the operating system to create a new file, the variable actual_permissions would be the actual permissions that the operating system would use to create the file:

requested_permissions = 0666;
actual_permissions = requested_permissions & ~umask();

Compliant Solution 1

For OpenBSD and Linux operating systems, any file created will have mode S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH (0666), as modified by the process's umask value. (See fopen(3) in the OpenBSD Manual Pages [OpenBSD].)

Compliant Solution (fopen_s(), C11 Annex K)

The C11 Annex K function The fopen_s() function defined in ISO/IEC TR 24731-2006 provides some control over file access permissions. Specifically, the report states: " can be used to create a file with restricted permissions [ISO/IEC 9899:2011]:

If the file is being created, and the first character of the mode string is not 'u', to the extent that the underlying system supports it, the file shall have a file permission that prevents other users on the system from accessing the file. If the file is being created and the first character of the mode string is 'u', then by the time the file has been closed, it shall have the system default file access permissions.

The u character can be thought of as standing for "umask," meaning that these are the same permissions that the file would have been created with had it been created by fopen(). In this compliant solution, the u mode character is omitted so that the file is opened with restricted privileges (regardless of the umask):

...
File *fptr;char *file_name;
FILE *fp;

/* Initialize file_name */

errno_t res = fopen_s(&fptrfp, file_name, "wwx");
if (res != 0) {
  /* Handle Errorerror */
}

On Windows, fopen_s() will create the file with security permissions based on the user executing the application.

...

For more controlled permission schemes, consider using the CreateFile() function and specifying the SECURITY_ATTRIBUTES parameter.

Noncompliant Code Example (open(),

...

POSIX)

Using the POSIX function open() function to create a file but failing to provide access permissions for that file may cause that the file to be created with unintended overly permissive access permissions. This omission has been known to lead to vulnerabilities; for instance—for example, CVE-2006-1174.

char *file_name;
int fd;

/* Initialize file_name */


...
int fd = open(file_name, O_CREAT | O_WRONLY); 
/* accessAccess permissions arewere missing */

if (fd == -1){
  /* Handle Errorerror */
}

This example also violates EXP37-C.

...

Call functions with the correct number and type of arguments.

Compliant Solution

...

(open(), POSIX)

Access permissions for the newly created file should be specified in the call third argument to open(). Again, the permissions may be influenced are modified by the value of umask().

...char *file_name;
int file_access_permissions;

/* Initialize file_name and file_access_permissions */

int fd = open(
  file_name,
  O_CREAT | O_WRONLY,
  file_access_permissions
);
if (fd == -1){
  /* Handle Errorerror */
}

John Viega and Matt Messier also provide the following advice [Viega 2003]:

Do not rely on setting the umask to a "secure" value once at the beginning of the program and then calling all file or directory creation functions with overly permissive file modes. Explicitly set the mode of the file at the point of creation. There are two reasons to do this.

...

First, it makes the code clear; your intent concerning permissions is obvious. Second, if an attacker managed to somehow reset the umask between your adjustment of the umask and any of your file creation calls, you could potentially create sensitive files with wide-open permissions.

Non-compliant Code Example 3 (Win32)

Compliant Solution 3 (Win32)

Risk Assessment

Creating files without appropriate with weak access permissions may allow unintended access to those files.

References

...

Automated Detection

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

Bibliography

...

...

...

Image Added Image Added Image Added

...