
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 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 filesmodel to protect file access. When a new file is created, the file access permissions of the file immediately dictate who may access or operate on the file. If When a program creates a file with insufficiently restrictive access permissions, an attacker may read or modify the file before the program is able can modify the permissions. Consequently, any file created by a program files 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.
unauthorized file access.
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 of any file created are implementation-defined, and are likely to grant untrusted users the ability to read or modify the file. and may not prevent unauthorized access:
Code Block | ||
---|---|---|
| ||
Writer out = new FileWriter("file");
|
Implementation Details (POSIX)
Wiki Markup |
---|
On POSIX-compliant systems, the permissions may be restricted by the value of the POSIX C {{umask()}} function \[[Open Group 2004|AA. Bibliography#Open Group 04]\]. |
Wiki Markup |
---|
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: |
Code Block |
---|
requested_permissions = 0666;
actual_permissions = requested_permissions & ~umask();
|
Wiki Markup |
---|
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 (POSIX, Java 1.7)
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, although but the actual permissions are platform-specific. This compliant solution defines sufficiently restrictive permissions for POSIX platforms:
Code Block | ||
---|---|---|
| ||
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)) { // writeWrite data }; |
Analogous permissions can be used for a Windows-based compliant solution.
Exceptions
FIO03FIO01-J-EX0: If When 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 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-JFIO03-EX1: Files that do not contain sensitive privileged 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 uponIf files are created without appropriate permissions, an attacker may read or write to the files, possibly resulting in compromised system integrity and information disclosure.
Rule | Severity | Likelihood |
---|
Detectable | Repairable | Priority | Level |
---|
FIO01-J |
Medium | Probable |
No |
No | P4 | L3 |
Automated Detection
...
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
CodeSonar |
| JAVA.IO.PERM.ACCESS | Accessing file in permissive mode | ||||||
Parasoft Jtest |
| CERT.FIO01.ASNF | Avoid implicit file creation when a String is passed as an argument | ||||||
PVS-Studio |
| V5318 |
Related Guidelines
...
...
...
...
ISO/IEC TR 24772:2010 | Missing or Inconsistent Access Control [XZN] |
...
...
Incorrect Execution-Assigned Permissions |
...
...
...
Incorrect Default Permissions |
...
...
...
-732, |
...
Incorrect Permission Assignment for Critical Resource |
Android Implementation Details
Creating files with weak permissions may allow malicious applications to access the files."
Bibliography
Wiki Markup |
---|
\[[API 2006|AA. Bibliography#API 06]\]
\[[CVE|AA. Bibliography#CVE]\]
\[[J2SE 2011|AA. Bibliography#J2SE 11]\]
\[[OpenBSD|AA. Bibliography#OpenBSD]\]
\[[Open Group 2004|AA. Bibliography#Open Group 04]\] "The {{open}} function," and "The {{umask}} function"
\[[Viega 2003|AA. Bibliography#Viega 03]\] Section 2.7, "Restricting Access Permissions for New Files on UNIX"
\[[Dowd 2006|AA. Bibliography#Dowd 06]\] Chapter 9, "UNIX 1: Privileges and Files" |
[API 2014] | |
[CVE] | |
Chapter 9, "UNIX 1: Privileges and Files" | |
[OpenBSD] | |
"The | |
Section 2.7, "Restricting Access Permissions for New Files on UNIX" |
...
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