Page History

Files on multiuser systems are generally owned by a particular user. The owner of the file can specify which other users on the system should be allowed to access the contents of these files.

These file systems use a privileges and permissions model to protect file access. When a file is created, the file access permissions dictate who may access or operate on the file. When a program creates a file with insufficiently restrictive access permissions, an attacker may read or modify the file before the program can modify the permissions. Consequently, files must be created with access permissions that prevent unauthorized file access.

Noncompliant Code Example

The constructors for FileOutputStream and FileWriter do

Creating a file with insufficiently restrictive access permissions may allow an unprivileged user to access that file. Although access permissions are heavily dependent on the 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 is not able to alter them. (See recommendation 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 of any file created are implementation-defined. and may not prevent unauthorized access:

char *file_name;
FILE *fp;

/* initialize file_name */

fp = fopen(file_name, "wWriter out = new FileWriter("file");
if (!fp){
  /* Handle error */
}

Implementation Details

On POSIX-compliant systems, the permissions may be restricted by the value of the POSIX {{umask()}} function \[[Open Group 2004|AA. Bibliography#Open Group 04]\].

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|AA. Bibliography#Viega 03]\]. 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();

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)}}|http://www.openbsd.org/cgi-bin/man.cgi?query=open&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html] in the OpenBSD Manual Pages \[[OpenBSD|AA. Bibliography#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|AA. Bibliography#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.

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).

char *file_name;
FILE *fp;

/* initialize file_name */

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

Noncompliant Code Example (open(), POSIX)

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.

char *file_name;
int fd;

/* initialize file_name */

fd = open(file_name, O_CREAT | O_WRONLY);
/* access permissions were missing */

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

This example also violates rule EXP37-C. Call functions with the arguments intended by the API.

Compliant Solution (open(), POSIX)

Access permissions for the newly created file should be specified in the third argument to open(). Again, the permissions 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 error */
}

John Viega and Matt Messier also provide the following advice \[[Viega 2003|AA. Bibliography#Viega 03]\]:

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.

Risk Assessment

The ability to determine if an existing file has been opened or a new file has been created provides greater assurance that a file other than the intended file is not acted upon.

Automated Detection

TODO

Related Guidelines

...

Compliant Solution (Java 1.6 and Earlier)

Java 1.6 and earlier lack a mechanism for specifying default permissions upon file creation. Consequently, the problem must be avoided or solved using some mechanism external to Java, such as by using native code and the Java Native Interface (JNI).

Compliant Solution (POSIX)

The  I/O facility java.nio provides classes for managing file access permissions. Additionally, many of the methods and constructors that create files accept an argument allowing the program to specify the initial file permissions.

The Files.newByteChannel() method allows a file to be created with specific permissions. This method is platform-independent, but the actual permissions are platform-specific. This compliant solution defines sufficiently restrictive permissions for POSIX platforms:

Path file = new File("file").toPath();

// Throw exception rather than overwrite existing file
Set<OpenOption> options = new HashSet<OpenOption>();
options.add(StandardOpenOption.CREATE_NEW);
options.add(StandardOpenOption.APPEND);

// File permissions should be such that only user may read/write file
Set<PosixFilePermission> perms =
    PosixFilePermissions.fromString("rw-------");
FileAttribute<Set<PosixFilePermission>> attr =
    PosixFilePermissions.asFileAttribute(perms);

try (SeekableByteChannel sbc =
         Files.newByteChannel(file, options, attr)) {
  // Write data
};

Exceptions

FIO01-J-EX0: When a file is created inside a directory that is both secure and unreadable by untrusted users, that file may be created with the default access permissions. This could be the case if, for example, the entire file system is trusted or is accessible only to trusted users (see FIO00-J. Do not operate on files in shared directories for the definition of a secure directory).

FIO01-J-EX1: Files that do not contain privileged information need not be created with specific access permissions.

Risk Assessment

If files are created without appropriate permissions, an attacker may read or write to the files, possibly resulting in compromised system integrity and information disclosure.

Automated Detection

Related Guidelines

...

...

...

...

...

...

...

...

...

...

...

...

Android Implementation Details

Creating files with weak permissions may allow malicious applications to access the files.

Bibliography

...

Image Added Image Added Image Added

Bibliography

\[[API 2006|AA. Bibliography#API 06]\]
\[[CVE|AA. Bibliography#CVE]\]
\[[J2SE 2011|AA. Bibliography#J2SE 11]\] The try-with-resources Statement

FIO01-J. Do not expose buffers created using the wrap() or duplicate() methods to untrusted code      12. Input Output (FIO)      FIO05-J. Do not create multiple buffered wrappers on a single InputStream