...
| Wiki Markup |
|---|
On POSIX-compliant systems, the permissions may be restricted by the value of the POSIX {{umask()}} function \[[Open Group 04|AA. References#OpenBibliography#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 03|AA. References#ViegaBibliography#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: |
...
| 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. References#OpenBSDBibliography#OpenBSD]\].) |
Compliant Solution (fopen_s() ISO/IEC TR 24731-1)
| Wiki Markup |
|---|
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. References#ISOBibliography#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.
...
| Wiki Markup |
|---|
John Viega and Matt Messier also provide the following advice \[[Viega 03|AA. References#ViegaBibliography#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.
...
References
| Wiki Markup |
|---|
\[[CVE|AA. References#CVEBibliography#CVE]\] \[[ISO/IEC 9899:1999|AA. References#ISOBibliography#ISO/IEC 9899-1999]\] Section 7.19.5.3, "The {{fopen}} function" \[[ISO/IEC PDTR 24772|AA. References#ISOBibliography#ISO/IEC PDTR 24772]\] "XZN Missing or Inconsistent Access Control" \[[MITRE 07|AA. References#MITREBibliography#MITRE 07]\] [CWE-279|http://cwe.mitre.org/data/definitions/279.html], "Insecure Execution-assigned Permissions," and [CWE-276|http://cwe.mitre.org/data/definitions/276.html], "Insecure Default Permissions," [CWE-732|http://cwe.mitre.org/data/definitions/732.html], "Incorrect Permission Assignment for Critical Resource" \[[OpenBSD|AA. References#OpenBSDBibliography#OpenBSD]\] \[[Open Group 04|AA. References#OpenBibliography#Open Group 04]\] "The {{open}} function," and "The {{umask}} function" \[[ISO/IEC TR 24731-1:2007|AA. References#SOBibliography#SO/IEC TR 24731-1-2007]\] Section 6.5.2.1, "The {{fopen_s}} function" \[[Viega 03|AA. References#ViegaBibliography#Viega 03]\] Section 2.7, "Restricting Access Permissions for New Files on UNIX" \[[Dowd 06|AA. References#DowdBibliography#Dowd 06]\] Chapter 9, "UNIX 1: Privileges and Files" |
...