One of the most difficult to understand aspects of Linux and Linux/Unix like operating systems are file permissions. While file permission issues can also plague other operating systems, they are well worth the mention from a security standpoint. Over-sharing file permissions can in fact lead to a compromise if in the event an attacker can identify improper file permissions. This can originate from a binary or, configuration file with credentials. This document will discuss how to find and properly apply permissions to files in Linux/Unix based operating systems.
Introduction
Like any form of access permission, rights or rules -- file systems are no different. Over sharing directories, objects (files) or configuration data can result in a system compromise. This article will explore how you can quickly find files, the types of files and data that you are over-sharing before they become impactful to your environment, data and other digital assets.
Understanding Linux File Permissions
There are 3 primary groups of Linux / Unix file system permissions and a 4th set known as: Sticky bit, setgid and setuid. The Linux / Unix file permissions are set as follows: 0000. The chart below will describe the groups and what they control:
| suid / sticky bit | User | Group | Other | Value | Fig. |
| 1000 | 400 | 40 | 4 | 1444 | 1 |
| 2000 | 400 | 40 | 4 | 2444 | 2 |
| 4000 | 400 | 40 | 4 | 4444 | 3 |
Brief example of file permissions
In (Fig. 1) figure 1 we see that the permissions are 1444. While these don't mean anything yet, the permissions break down can be understood as follows:
File permission breakdown.
The values in the far right (Mode) column: -rw-r--r-- correspond to a grouping of values which are in a range of 0 - 7. The chart below describes each bit which can be added:
| Permission Value | Binary | Octal | Grants |
If we break down the groups of permissions on the first file we've selected (-rw-r--r--) we can come up with the following details:
So how do we understand the permissions above in decimal format? If we go back to the chart, we see that the RW in group 1 (user) is set to 6 (Read/Write). The next group, group is set to (4) and the other is also set to 4 which is read. If we want to see the permissions in their 644, 755, or 777 formats we can issue the stat command which will provide us with that information as shown below:
stat command with %a and %n options for file permissions and object.
If we run the stat -c '%a %n' against a group of files or, specific files (in our case) we can see the return is 644 and, 1755. The larger of the numbers with the 1755 has the stickybit set (more on this later).
How are Improper Permissions Found?
In the most simplistic approach, we will take a look at file system configuration issues and then we will continue to escalate up the chain to provide you with the best examples and recourse to security you have. The first utility that we will explore for file auditing will be the find command in Linux/Unix. The parameters that we will leverage will be -type f,d -perm 777 as well as redirecting error output to /dev/null so that we are not inundated with garbage data. That additional command will be as follows: 2>/dev/null.
By issuing the cd / command from a root user will place you at the root of the file system (do not confuse this with the root user. If you do not see a # at your terminal; you're not root). Once that command is issued, you should then issue the following find command: find . -type f,d -perm 777 2>/dev/null. If you'd like to redirect the output to another file so you can import it into a report you can issue the following: find . -type f,d -perm 777 2>/dev/null >> file_permissions.log. In the example we are running we will be doing so from a server that was spun up for "convenience" rather then security:
Example showing all files with improper permissions.
Example showing more than our fair share of files we should be allowing 777 on.
You can see from both examples that we are in fact sharing a bunch of files in the web root that should not have the 777 permission assigned. Additionally, we are sharing more than 37,000 files with permissions well above what they should be!
Now, you might be thinking "777 is all I really need to worry about, right? Right?" Well, the answer to this is NO! There are other improper file permissions that can be applied to files that aren't just 777. In Linux and Unix there is a permission (sticky bit) called the suid / suid root or stickybit (we see later how file permissions are grouped). For the suid bitsets that we should worry about, we need to search for the following:
| Bit set | Description |
| 1000 or -t option | stickybit; When set on a directory only the owner of a file within the directory can delete or rename a file. Commonly associated with directories like or similar to /tmp to prevent other users from tampering with files belonging to others. |
| 2000 -s option | setgid; This bitset inherits the group membership of the parent directory rather than the executing user. |
| 4000 -s or -S option | setuid; When this bit set is set, the process that is spawned runs with the privileges / permissions of the file owner rather than the executing user. This is often issued to files that require elevated permissions to perform a task. |
Table displaying the bitset numbers
If we are interested in writing a script, or setting up a search for all the files / folders that have the bitsets enabled. We could run the following shell script. Please keep in mind that you will need to redirect the output to another file if and when we are porting this information. E.g: ./findpem.sh > permission_search.log
| Permissions | User / Owner | Group | Other |
|---|---|---|---|
| Read | |||
| Write | |||
| Execute | |||
| Total Value(s): | 0 | 0 | 0 |
Monitoring File Permissions
File permissions can be monitored in a few ways. The first and best way to perform file monitoring is with a tool called tripwire tripwire operates by creating a listing of files or directories that you'd like to monitor for changes. Changes can be writes, permission changes, files added, deleted and so on. You can find more information about Tripwire Setup & Security for Linux operating systems at the link provided.
Alternative methods of file system security include utilizing auditd / auditctl in order to monitor permissions of files. This can be written into your audit.log file and fed directly into a SIEM for detections. Once we start on our SIEM and log and log detection series we will cover this in much more detail -=]
Conclusion
- We learned how permissions are calculated and displayed.
- Reviewed the permissions for users, groups and other.
- Learned how to utilize the stat command to return the octal value of an objects permission(s).
- How to search for and find objects that may have been improperly configured.
- Provided a graphic calculator for permissions and values to set for your objects, directories and other files.
- Created audit rules for file permission changes
Should there be any additional information, links or updates to this document or methods of testing please check the: Monitoring File Permissions and when available to this document the: Abusing File Permissions segment(s).
