Reason to not use chmod -R 777 on internal server for project source code?
However, after putting some thought into it I can't come up with a reason why shared executable code on an internal server shouldn't have 777 permissions.
Because you're not only trusting every user - which might be reasonable on an internal server where "everybody" who has access should have that control - you're also trusting every process on that server. The web server. The SSH server. The DHCP client. Every scheduled task and every service. Even processes running as "nobody" and "nogroup". All sorts of processes that might be leveraged by an attacker to gain or expand their access.
Because if you're going to be that sloppy in internal development, someone's going to be that sloppy on a Production or Customer system, because "that's how we fixed it internally".
Because an attacker will delight in finding that little system that's only internal and isn't important or protected, see weaknesses like writable web application files, use them to get onto the system and start leveraging it to get somewhere. I'll bet the passwords people use on that system also work on other, more valuable, internal systems. Maybe you guys use the same root password across servers, too? That's always a fun one to find.
I'm gonna second @gowenfawr and say that breeding better chimpanzees is a goal unto itself here. (now I will extrapolate wildly about your corporate culture)
At my software development company, we've been seeing an increasing trend of customers asking for evidence of our security practices not just in production environments, but also in our development process, and corporate IT in general. This is a perfectly reasonable request because:
- Sloppy security in prod puts their data at risk. See: Equifax breach of 2017.
- Sloppy security in dev leads to developers writing sloppy products. Really though, the attitude that security is important needs to come from management to give developers security training, and time to do proper code reviews, and the willingness to prioritize fixing security flaws over customer features. Allowing sloppy practices like is evidence that corporate culture does not promote security.
- Sloppy security practices in IT leads to viruses in the network which can lead to viruses in the code. See the famous Linux backdoor attempt of 2003 where someone broke in electronically to the backup code repository and inserted a malicious code change, hoping that it would eventually get merged into the main repo.
So is this a decision that you would be proud to tell a customer about?
Bottom line: Principle of least privilege is one of the most fundamental secure coding principles. It's a mindset that should be part of any software development process. It's about asking the question "Is it necessary to weaken our security like this?", rather than "Can anyone prove that this is dangerous?". The hackers are always smarter than you are.
Of course if chmod 777 is necessary for some reason, then it becomes the least privilege, and there could be a legitimate security discussion to be had here, but it sounds like there isn't; this is just laziness. That does not give me confidence that principle of least privilege is being followed in the product itself, for example how data is stored, how much extra data is returned from API calls, what information is being logged, or wherever else principle of least privilege is relevant to your product.
Unless the program requires write permissions, I am confused as to why your coworker used chmod -R 777 /opt/path/to/shared/folder when chmod -R 775 /opt/path/to/shared/folder would still allow read and execute permissions, and achieve the desired access.
Given your team members are the only ones with access to the server, and you trust them. Having global write access is not necessarily a bad thing. But the purpose is to also prevent malicious or rogue programs from modifying or deleting the files. Ransomware could be an example, which is executed by Alice, with user permissions.
- /home/alice/ --- (drwxrwxrwx alice alice)
- /home/bob/ --- (drwxrwx--- bob bob)
For the above scenario, the ransomware executed by Alice would encrypt and overwrite all files she has to write access to. Given Alice does not belong to group bob and /home/bob/ does not have global rwx Alice has zero access. However, if Bob was to run the ransomware with user permissions, Bob has rwx permissions because /home/alice/ uses global rwx permissions. So, now both Alice and Bob's home directories will be encrypted by the ransomware.
Adding users to a group is quite simple, Linux: Add User to Group (Primary/Secondary/New/Existing). This will add the username: alice, to the bob group. Chown -R bob:bob where user:group owns the directory, recursively. chmod -R 750 will recursively provide rwxr-x--- permissions, so Alice can read and execute within /home/bob/ directory, but cannot write.
sudo adduser alice bobsudo chown -R bob:bob /home/bob/sudo chmod -R 750 /home/bob/
The principle of least access is mainly to protect against malicious users. However, malicious programs are also a very serious concern. This is why global read, write and execute, together ------rwx is a very bad security principle. This idea is done by adding alice to the bob group. Now the user alice has r-x permissions to /home/bob/ while other users outside bob group cannot, except root. Equally, if Bob wanted to share files with Alice, but does not want Alice to have group access, a new group, called AB where Alice and Bob are in the group could be created. Now a directory /opt/AB_share/ (rwxrwx---) could be created, and the above commands applied. Only those within the AB group would have access.