You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

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. Also, when setting access permissions, it is important to make sure that an attacker is not able to alter them.

Noncompliant Code Example

The constructors for FileOutputStream and FileWriter do not allow the programmer to explicitly specify file access permissions. In this noncompliant code example, if the constructor creates a new file, the access permissions are implementation-defined.

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

Exceptions

FIO03-EX0: This guideline is not required for files created in secure directories, although it is still a good idea.

FIO03-EX1: This guideline is not required for files that do not contain sensitive information.

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.

Guideline

Severity

Likelihood

Remediation Cost

Priority

Level

FIO03-J

medium

probable

high

P4

L3

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, "Insecure Execution-assigned Permissions"

MITRE CWE: CWE-276, "Insecure 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"


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

  • No labels