FIO03-J. Create files with appropriate access permissions

Many filesystems provide access to their files to multiple users, and not all of the users are trustworthy. These filesystems generally use a privileges and permissions system to prevent untrusted users from accessing sensitive files. When a new file is created, the access permissions of the file immediately dictate who may access or operate on the file. If a program creates a file with insufficiently restrictive access permissions, an attacker may read or modify the file before the program is able modify the permissions. Consequently, any file created by a program must be created with access permissions that prevent untrusted users from accessing or modifying the file.

Java provides several methods for creating files. Furthermore, several classes, such as FileOutputStream can create files in their constructors. Prior to Java 1.7, these methods were unable to specify access permissions when creating files. In these cases, the problem of making sure the file is not created with insufficient permissions falls outside the program and must be handled by anyone executing the program.

Java 1.7 new I/O facility (java.nio) provides a rich set of classes for managing file access permissions. Furthermore, many of the methods and constructors that create files accept an argument allowing the program to specify initial permissions of the file. If a file might otherwise be accessable to untrusted users, a Java 1.7 program must create the file with sufficiently restrictive access permissions.

Noncompliant Code Example

The constructors for FileOutputStream and FileWriter do not allow the programmer to explicitly specify file access permissions. This applies to Java 1.7, as well as previous versions of Java.

In this noncompliant code example, if the constructor creates a new file, which is accessible by untrusted users, the access permissions are implementation-defined, and are likely to grant untrusted users the ability to read or modify the file.

Writer out = new FileWriter("file");

Implementation Details (POSIX)

On POSIX-compliant systems, the permissions may be restricted by the value of the POSIX C 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:

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) in the OpenBSD Manual Pages [[OpenBSD]].)

Compliant Solution (POSIX, Java 1.7)

The Files.newByteChannel() method allows a file to be created with specific permissions. This method is platform-independent, although the permissions are platform-specific.

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 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
};

Analogous permissions can be used for a Windows-based compliant solution.

Exceptions

FIO03-EX0: If a file is created inside a directory that is both secure and unreadable by untrusted users, then that file may be created with the default access permissions. See FIO07-J. Do not create temporary files in shared directories for the definition of a secure directory. This could be the case if, for example, the entire filesystem is trusted, or is accessible only to trusted users.

FIO03-EX1: Files that do not contain sensitive information need not be created with specific access 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

CERT C++ Secure Coding Standard: FIO06-CPP. Create files with appropriate access permissions

CERT C Secure Coding Standard: FIO06-C. Create files with appropriate access permissions

MITRE CWE: CWE-279, "Incorrect Execution-Assigned Permissions"

MITRE CWE: CWE-276, "Incorrect Default Permissions"

MITRE CWE: CWE-732, "Incorrect Permission Assignment for Critical Resource"

Bibliography

[[API 2006]]
[[CVE]]
[[J2SE 2011]]
[[OpenBSD]]
[[Open Group 2004]] "The open function," and "The umask function"
[[Viega 2003]] Section 2.7, "Restricting Access Permissions for New Files on UNIX"
[[Dowd 2006]] Chapter 9, "UNIX 1: Privileges and Files"

FIO02-J. Do not assume that read() has filled all the elements of an array      12. Input Output (FIO)      FIO04-J. Do not open non-regular files when accessing regular files