|
So I read in a Linux book that the reason the current directory, aka ".", is not in PATH is because it is insecure to do so. How? What vulnerability does this create? |
|
Yes, it is definitely insecure. If you create a directory with the following contents, it is a security flaw:
If your So don't put the dot in your So why shouldn't we put . at the end of our PATH? That way /bin/cd will be seen first and run instead of ./cd
(01 Jul '10, 11:23)
Kevin M
Putting . at the end should not cause problem. But you propably get no message "Command atp-get not found, try apt-get". If a evil directory contains a program you don't have installed, it can harm you PC. So if you don't have got apt-get installed, an evil ./apt-get file is dangerous.
(01 Jul '10, 12:40)
guerda
If you are working just as a user, this is not very important. The old "rm -rf /" won't work. It is a huge vuknerability if you are running as root. Generally, root should never ever have . in the PATH, but users don't have to be so paranoid.
(01 Jul '10, 22:30)
codebunny
For sure it's not that harmful as normal user. But it doesn't cost you massive work to say "./mysimpleprogram". And you are sure you are executing the file in the current directory.
(02 Jul '10, 05:41)
guerda
1
Plus "rm -rf /" is not the only command that I most definitely do not want to run. How about "rm -rf ~"? If you have recent backups, then it's a significant inconvenience. If you don't have recent backups then it's more than a significant inconvenience.
(02 Jul '10, 12:14)
Kevin M
1
While it may not seem that users need to be as paranoid, they in fact do. You don't have to compromise the most effective security practices, only the weakest of them to get into the box. There are plenty of local vulnerabilities that go ignored because an admin doesn't think it's a risk since only it's accessible to local users. All it takes is one of the users compromised and you have an issue. Best practices are not just for root.
(13 Jul '10, 19:07)
rfelsburg ♦
showing 5 of 6
show 1 more comments
|
|
The risk is not worth the reward. In a properly configured Linux environment, all executables should be in a few standard directories. This is part of the FSSTD and is generally considered a good practice as all files with the same function are in the same place. Unlike the directory structure of Windows, executing a command in a local directory is more of the exception than the rule. Mostly, it will be to run ./configure or something similar. Since doing otherwise is so rare, it causes you to have to stop for a moment and think before doing something stupid. As for security, you can imagine all the things that could go wrong if any file could be executed at random. Unlike Windows, Linux does not require a special filename extension (.exe, .com, .bat) to be executable. I know that some fs types, such as NTFS, that don't have Linux permissions can be granted all permissions by default. This includes the execute permission. That means that you could wonder into a directory and accidentally execute a file at random by using tab-complete. Mostly, this would just issue a lot of "command not found", but if just the right phrase appeared, you might have trouble. This is just one example that doesn't even require ill intentions. I'll let your imagination figure out some more. |
