Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

When setting access permissions, it is important to make sure that an attacker is not able to 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 allow the programmer to explicitly specify file access permissions. In this noncompliant code example, if the call to fopen() creates a new file, the access permissions are implementation-defined.

Code Block
bgColor#FFCCCC
langc
char *file_name;
FILE *fp;

/* initialize file_name */

fp = fopen(file_name, "w");
if (!fp){
  /* Handle error */
}

...

On POSIX-compliant systems, the permissions may be restricted by the value of the POSIX umask() function [Open Group 2004].

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:

...

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(), ISO/IEC TR 24731-1)

The ISO/IEC TR 24731-1 function fopen_s() can be used to create a file with restricted permissions [ISO/IEC TR 24731-1:2007]:

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.

...

Code Block
bgColor#ccccff
langc
char *file_name;
FILE *fp;

/* initializeInitialize file_name */

errno_t res = fopen_s(&fp, file_name, "w");
if (res != 0) {
  /* Handle error */
}

...

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

...

This example also violates EXP37-C. Call functions with the correct number and type of arguments.

Compliant Solution (open(), POSIX)

...

Code Block
bgColor#ccccff
langc
char *file_name;
int file_access_permissions;

/* initializeInitialize file_name and file_access_permissions */

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

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.

...

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

Related Guidelines

...

...

...

...

...

24731-1:2007Section 6.5.2.1, "The fopen_s

...

Function"
ISO/IEC TR 24772Missing or Inconsistent Access Control [XZN]
MITRE CWE

...

...

276,

...

Insecure

...

default permissions

...


...

...

...

279,

...

Insecure

...

execution-assigned permissions

...


...

...

Incorrect permission assignment for critical resource

...

Bibliography

[CVE] 
[Dowd 2006]Chapter 9, "UNIX 1: Privileges and Files"
[OpenBSD] 
[Open Group 2004]"The open

...

Function"

...


"The umask

...

Function"
[Viega 2003]Section 2.7, "Restricting

...

Access Permissions for New Files on UNIX"

...