Mixing
![Learning an uncommon technology when co-workers are not cooperative [closed]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjbpfN9tAutmK93bJRC3ZoROZzi2TJDms5n8_qJuhgE0a9b52OOHayv3NGT8igAdFL7byXNst-_1DZK5SjrIJ28_6RQPUpBROqMs5s6jo-ZsjX8kjDwfxJufIitH3TaQRXWaGSQKRQib-f/s72-c/1.jpg)
Reason to not use chmod -R 777 on internal server for project source code?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
42
down vote
favorite
From my days of amateur web development the principle of least privilege has beaten into me not to use chmod -R 777 dir. I have personally never needed it, so I've never used it.
I now work on a development team professionally, and we recently moved executable code to a shared internal server. Only people from the company can access the server and we trust everyone at our company. The code isn't particularly sensitive, anyway.
Trying to run a script†that another team member wrote into the shared folder caused a permissions error, so "just to check if it would otherwise work" a coworker ran chmod -R 777 /opt/path/to/shared/folder on the project. Once it did work the coworker said it's fine to leave it as is instead of switching to a more controlled groups solution for us.
Because I am a chimpanzee I want to speak up and say this is bad practice and we should change it to a groups solution. 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.
From a security standpoint, is there any reason to change our project folder's permissions from 777 to something tied down a little tighter with groups?
†We can't change this scripts' permission requirements.
linux permissions file-access
asked Aug 23 at 19:33
user1717828
1,793819
add a comment |Â
up vote
42
down vote
favorite
From my days of amateur web development the principle of least privilege has beaten into me not to use chmod -R 777 dir. I have personally never needed it, so I've never used it.
I now work on a development team professionally, and we recently moved executable code to a shared internal server. Only people from the company can access the server and we trust everyone at our company. The code isn't particularly sensitive, anyway.
Trying to run a script†that another team member wrote into the shared folder caused a permissions error, so "just to check if it would otherwise work" a coworker ran chmod -R 777 /opt/path/to/shared/folder on the project. Once it did work the coworker said it's fine to leave it as is instead of switching to a more controlled groups solution for us.
Because I am a chimpanzee I want to speak up and say this is bad practice and we should change it to a groups solution. 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.
From a security standpoint, is there any reason to change our project folder's permissions from 777 to something tied down a little tighter with groups?
†We can't change this scripts' permission requirements.
linux permissions file-access
asked Aug 23 at 19:33
user1717828
1,793819
37
Tangential, butchmod -R 777will make all your files executable. You don't want that.
– Reid
Aug 23 at 23:47
add a comment |Â
up vote
42
down vote
favorite
up vote
42
down vote
favorite
From my days of amateur web development the principle of least privilege has beaten into me not to use chmod -R 777 dir. I have personally never needed it, so I've never used it.
I now work on a development team professionally, and we recently moved executable code to a shared internal server. Only people from the company can access the server and we trust everyone at our company. The code isn't particularly sensitive, anyway.
Trying to run a script†that another team member wrote into the shared folder caused a permissions error, so "just to check if it would otherwise work" a coworker ran chmod -R 777 /opt/path/to/shared/folder on the project. Once it did work the coworker said it's fine to leave it as is instead of switching to a more controlled groups solution for us.
Because I am a chimpanzee I want to speak up and say this is bad practice and we should change it to a groups solution. 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.
From a security standpoint, is there any reason to change our project folder's permissions from 777 to something tied down a little tighter with groups?
†We can't change this scripts' permission requirements.
linux permissions file-access
asked Aug 23 at 19:33
user1717828
1,793819
From my days of amateur web development the principle of least privilege has beaten into me not to use chmod -R 777 dir. I have personally never needed it, so I've never used it.
I now work on a development team professionally, and we recently moved executable code to a shared internal server. Only people from the company can access the server and we trust everyone at our company. The code isn't particularly sensitive, anyway.
Trying to run a script†that another team member wrote into the shared folder caused a permissions error, so "just to check if it would otherwise work" a coworker ran chmod -R 777 /opt/path/to/shared/folder on the project. Once it did work the coworker said it's fine to leave it as is instead of switching to a more controlled groups solution for us.
Because I am a chimpanzee I want to speak up and say this is bad practice and we should change it to a groups solution. 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.
From a security standpoint, is there any reason to change our project folder's permissions from 777 to something tied down a little tighter with groups?
†We can't change this scripts' permission requirements.
linux permissions file-access
asked Aug 23 at 19:33
user1717828
1,793819
asked Aug 23 at 19:33
user1717828
1,793819
asked Aug 23 at 19:33
user1717828
1,793819
asked Aug 23 at 19:33
user1717828
1,793819
1,793819
37
Tangential, butchmod -R 777will make all your files executable. You don't want that.
– Reid
Aug 23 at 23:47
add a comment |Â
37
Tangential, butchmod -R 777will make all your files executable. You don't want that.
– Reid
Aug 23 at 23:47
37
37
Tangential, but
chmod -R 777 will make all your files executable. You don't want that.– Reid
Aug 23 at 23:47
Tangential, but
chmod -R 777 will make all your files executable. You don't want that.– Reid
Aug 23 at 23:47
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
94
down vote
accepted
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.
answered Aug 23 at 20:34
gowenfawr
49.9k10107152
add a comment |Â
up vote
25
down vote
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.
answered Aug 23 at 23:24
Mike Ounsworth
35.2k1384127
4
"Allowing sloppy practices like is evidence" — maybe you out a word?
– Wildcard
Aug 24 at 18:09
add a comment |Â
up vote
7
down vote
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.
answered Aug 23 at 20:36
safesploit
1,097416
10
The main pillars of security is "availability". Giving everybody write permission means they also have deletion permission. All it takes is one accidental typo or bug for all of the shared resources to be damaged or deleted. Permissions help prevent malicious actions, but they also prevent accidental ones as well. Consider proper permissions a safety precaution even if security isn't an issue.
– Mr. Llama
Aug 23 at 20:53
3
The write component was actually necessary since the script (that we can't change) writes to various and sundry log files in the folder, among other things. The rest of your points are great.
– user1717828
Aug 24 at 0:45
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
94
down vote
accepted
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.
answered Aug 23 at 20:34
gowenfawr
49.9k10107152
add a comment |Â
up vote
94
down vote
accepted
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.
answered Aug 23 at 20:34
gowenfawr
49.9k10107152
add a comment |Â
up vote
94
down vote
accepted
up vote
94
down vote
accepted
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.
answered Aug 23 at 20:34
gowenfawr
49.9k10107152
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.
answered Aug 23 at 20:34
gowenfawr
49.9k10107152
answered Aug 23 at 20:34
gowenfawr
49.9k10107152
answered Aug 23 at 20:34
gowenfawr
49.9k10107152
answered Aug 23 at 20:34
gowenfawr
49.9k10107152
49.9k10107152
add a comment |Â
add a comment |Â
up vote
25
down vote
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.
answered Aug 23 at 23:24
Mike Ounsworth
35.2k1384127
4
"Allowing sloppy practices like is evidence" — maybe you out a word?
– Wildcard
Aug 24 at 18:09
add a comment |Â
up vote
25
down vote
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.
answered Aug 23 at 23:24
Mike Ounsworth
35.2k1384127
4
"Allowing sloppy practices like is evidence" — maybe you out a word?
– Wildcard
Aug 24 at 18:09
add a comment |Â
up vote
25
down vote
up vote
25
down vote
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.
answered Aug 23 at 23:24
Mike Ounsworth
35.2k1384127
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.
answered Aug 23 at 23:24
Mike Ounsworth
35.2k1384127
edited Aug 23 at 23:30
answered Aug 23 at 23:24
Mike Ounsworth
35.2k1384127
answered Aug 23 at 23:24
Mike Ounsworth
35.2k1384127
answered Aug 23 at 23:24
Mike Ounsworth
35.2k1384127
35.2k1384127
4
"Allowing sloppy practices like is evidence" — maybe you out a word?
– Wildcard
Aug 24 at 18:09
add a comment |Â
4
"Allowing sloppy practices like is evidence" — maybe you out a word?
– Wildcard
Aug 24 at 18:09
4
4
"Allowing sloppy practices like is evidence" — maybe you out a word?
– Wildcard
Aug 24 at 18:09
"Allowing sloppy practices like is evidence" — maybe you out a word?
– Wildcard
Aug 24 at 18:09
add a comment |Â
up vote
7
down vote
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.
answered Aug 23 at 20:36
safesploit
1,097416
10
The main pillars of security is "availability". Giving everybody write permission means they also have deletion permission. All it takes is one accidental typo or bug for all of the shared resources to be damaged or deleted. Permissions help prevent malicious actions, but they also prevent accidental ones as well. Consider proper permissions a safety precaution even if security isn't an issue.
– Mr. Llama
Aug 23 at 20:53
3
The write component was actually necessary since the script (that we can't change) writes to various and sundry log files in the folder, among other things. The rest of your points are great.
– user1717828
Aug 24 at 0:45
add a comment |Â
up vote
7
down vote
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.
answered Aug 23 at 20:36
safesploit
1,097416
10
The main pillars of security is "availability". Giving everybody write permission means they also have deletion permission. All it takes is one accidental typo or bug for all of the shared resources to be damaged or deleted. Permissions help prevent malicious actions, but they also prevent accidental ones as well. Consider proper permissions a safety precaution even if security isn't an issue.
– Mr. Llama
Aug 23 at 20:53
3
The write component was actually necessary since the script (that we can't change) writes to various and sundry log files in the folder, among other things. The rest of your points are great.
– user1717828
Aug 24 at 0:45
add a comment |Â
up vote
7
down vote
up vote
7
down vote
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.
answered Aug 23 at 20:36
safesploit
1,097416
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.
answered Aug 23 at 20:36
safesploit
1,097416
answered Aug 23 at 20:36
safesploit
1,097416
answered Aug 23 at 20:36
safesploit
1,097416
answered Aug 23 at 20:36
safesploit
1,097416
1,097416
10
The main pillars of security is "availability". Giving everybody write permission means they also have deletion permission. All it takes is one accidental typo or bug for all of the shared resources to be damaged or deleted. Permissions help prevent malicious actions, but they also prevent accidental ones as well. Consider proper permissions a safety precaution even if security isn't an issue.
– Mr. Llama
Aug 23 at 20:53
3
The write component was actually necessary since the script (that we can't change) writes to various and sundry log files in the folder, among other things. The rest of your points are great.
– user1717828
Aug 24 at 0:45
add a comment |Â
10
The main pillars of security is "availability". Giving everybody write permission means they also have deletion permission. All it takes is one accidental typo or bug for all of the shared resources to be damaged or deleted. Permissions help prevent malicious actions, but they also prevent accidental ones as well. Consider proper permissions a safety precaution even if security isn't an issue.
– Mr. Llama
Aug 23 at 20:53
3
The write component was actually necessary since the script (that we can't change) writes to various and sundry log files in the folder, among other things. The rest of your points are great.
– user1717828
Aug 24 at 0:45
10
10
The main pillars of security is "availability". Giving everybody write permission means they also have deletion permission. All it takes is one accidental typo or bug for all of the shared resources to be damaged or deleted. Permissions help prevent malicious actions, but they also prevent accidental ones as well. Consider proper permissions a safety precaution even if security isn't an issue.
– Mr. Llama
Aug 23 at 20:53
The main pillars of security is "availability". Giving everybody write permission means they also have deletion permission. All it takes is one accidental typo or bug for all of the shared resources to be damaged or deleted. Permissions help prevent malicious actions, but they also prevent accidental ones as well. Consider proper permissions a safety precaution even if security isn't an issue.
– Mr. Llama
Aug 23 at 20:53
3
3
The write component was actually necessary since the script (that we can't change) writes to various and sundry log files in the folder, among other things. The rest of your points are great.
– user1717828
Aug 24 at 0:45
The write component was actually necessary since the script (that we can't change) writes to various and sundry log files in the folder, among other things. The rest of your points are great.
– user1717828
Aug 24 at 0:45
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f192197%2freason-to-not-use-chmod-r-777-on-internal-server-for-project-source-code%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
37
Tangential, but
chmod -R 777will make all your files executable. You don't want that.– Reid
Aug 23 at 23:47