Risk associated with problematic linux permissions on files and libraries

Question

I started tweaking my linux system a while ago, before I understood the security risks related to having files with problematic permissions, such as 777.

I wanted to check if I had left some problematic permissions hanging so I tried find / -perm 777 and find / -perm 775.

I happen to find a lot of files matching those permissions, such as ruby gems, node modules, etc.

1. Is this normal and should I be worried?

2. Are there more permission numbers that are to be avoided (outside 777 and 775)?

3. Is there any more efficient way to check and/or correct bad permissions on a system scale?

Answer 1

1. Is this normal

Impossible for us to say without more data, but there are normal processes that can cause this.

and should I be worried?

Sloppiness is a more likely explanation than maliciousness, so, not deeply.

Are there more permission numbers that are to be avoided (outside 777 and 775)?

The numbers have meaning, and it's the meaning you need to worry about.

7 is octal for '111' which maps to 'rwx' and means 'read: yes, write: yes, execute: yes!'

5 is octal for '101' which maps to 'r-x' and means 'read: yes, write: no, execute: yes!'

You were told 777 is problematic because each digit means a different set of users: user, group, and other. 7 in the third digit means that other ('everyone not already specified') can write to the file, which is often a bad thing, because you shouldn't trust absolutely every user (including service and software users) on your system. Especially if they're writing to a program or a library that gets loaded into a program, they can make you execute malicious code.

Likewise, a 7 in the second digit can be a bad thing if you don't trust the group that it's granting write access to.

Is there any more efficient way to check and/or correct bad permissions on a system scale?

The best way is to use your distribution tools; see this answer which was written around SUID/SGID concerns but is equally valid for loose write permissions. Note that this will not catch the most likely cause of accidental looseness, which is installing software modules (e.g., with pip rather than apt) with a non-restrictive umask set for that user.