Why is this an issue?

In Unix file system permissions, the "others" category refers to all users except the owner of the file system resource and the members of the group assigned to this resource.

Granting permissions to this category can lead to unintended access to files or directories that could allow attackers to obtain sensitive information, disrupt services or elevate privileges.

What is the potential impact?

Unauthorized access to sensitive information

When file or directory permissions grant access to all users on a system (often represented as "others" or "everyone" in permission models), attackers who gain access to any user account can read sensitive files containing credentials, configuration data, API keys, database passwords, personal information, or proprietary business data. This exposure can lead to data breaches, identity theft, compliance violations, and competitive disadvantage.

Service disruption and data corruption

Granting write permissions to broad user categories allows any user on the system to modify or delete critical files and directories. Attackers or compromised low-privileged accounts can corrupt application data, modify configuration files to alter system behavior or disrupt services, or delete important resources, leading to service outages, system instability, data loss, and denial of service.

Privilege escalation

When executable files or scripts have overly permissive permissions, especially when combined with special permission bits that allow programs to execute with the permissions of the file owner or group rather than the executing user, attackers can replace legitimate executables with malicious code. When these modified files are executed by privileged users or processes, the attacker’s code runs with elevated privileges, potentially enabling them to escalate from a low-privileged account to root or administrator access, install backdoors, or pivot to other systems in the network.

How to fix it

Use the most restrictive permissions necessary. Grant execute permissions only to the owner (u+x), use the sticky bit (+t) for shared directories instead of setuid, and use octal modes that restrict "others" permissions (like 0754 instead of 0777).

Code examples

Noncompliant code example

steps:
  - bash: |
      chmod +x resource  # Noncompliant
      chmod u+s resource  # Noncompliant
      chmod 0777 resource  # Noncompliant
    displayName: 'Set permissions'

Compliant solution

steps:
  - bash: |
      chmod u+x resource
      chmod +t resource
      chmod 0754 resource
    displayName: 'Set permissions'

Resources

Documentation

Standards