3 ms·

Can you spoonfeed me here? If ~/bin is in my PATH and is writable to my user, what is the problem with /usr/local/bin being the same on my personal computer wi

Can you spoonfeed me here? If ~/bin is in my PATH and is writable to my user, what is the problem with /usr/local/bin being the same on my personal computer with a single human user?

theamk 6y ago
Base case (those are true AFAIK): - /usr/local/bin is in a "system-wide" default PATH, (and it is even in front of /bin !) - There is an important service, like Time Machine, which needs root access for important actions -- for example, to erase previous backups - There could be a vulnerability in an application which gets data from the internet -- for the sake of example, let's say it is "foo file viewer". This can be exploited for code execution. --- Case 1: Packages in ~/bin, /usr/local/bin is read-only: A user wants to look at a "foo file" from the internet. The file is malicious, it exploits "foo viewer" and gets local execution. It is a cryptolocker, so it encrypts all the user documents. The malware has installed trojaned "~/bin/sudo" wrapper, but since the user does not use "sudo" that often, it did not have a change to get executed. And none of the system services look into user's "~/bin". A week later, user notices that a document is encrypted. But the time machine backups are still OK. They reformat their machine, and then use time machine backup to restore the documents. Day is saved! --- Case 2: Packages in usr/local/bin: A user wants to look at a "foo file" from the internet. The file is malicious, it exploits "foo viewer" and gets local execution. It is a cryptolocker, so it encrypts all the user documents. The malware has installed a bunch of trojaned binaries, including "/usr/local/bin/touch" binary. Unfortunately, there is a LaunchDaemon which runs the script periodically which contains the line "touch /some/file". That is run as root, so in a short time, the malware gets root access. And it immediately used this access to disable time machine and delete all the backups. A week later, user notices that a document is encrypted. And the time machine backups are gone, too. Oh no! the documents are lost unless they pay the ransom! --- You might notice that some people may consider the scenario unrealistic: What if the user uses command line a lot, and is used to running "sudo"? What if a malware social engineers user by popping up a fake dialog asking for user password? Are there other privilege escalation methods? How often does this happen anyway? You should make your own decisions, but hopefully you at least see what the people are concerned about.

Can you spoonfeed me here? If ~/bin is in my PATH and is writable to my user, what is the problem with /usr/local/bin being the same on my personal computer with a single human user?

theamk 6y ago

Base case (those are true AFAIK): - /usr/local/bin is in a "system-wide" default PATH, (and it is even in front of /bin !) - There is an important service, like Time Machine, which needs root access for important actions -- for example, to erase previous backups - There could be a vulnerability in an application which gets data from the internet -- for the sake of example, let's say it is "foo file viewer". This can be exploited for code execution. --- Case 1: Packages in ~/bin, /usr/local/bin is read-only: A user wants to look at a "foo file" from the internet. The file is malicious, it exploits "foo viewer" and gets local execution. It is a cryptolocker, so it encrypts all the user documents. The malware has installed trojaned "~/bin/sudo" wrapper, but since the user does not use "sudo" that often, it did not have a change to get executed. And none of the system services look into user's "~/bin". A week later, user notices that a document is encrypted. But the time machine backups are still OK. They reformat their machine, and then use time machine backup to restore the documents. Day is saved! --- Case 2: Packages in usr/local/bin: A user wants to look at a "foo file" from the internet. The file is malicious, it exploits "foo viewer" and gets local execution. It is a cryptolocker, so it encrypts all the user documents. The malware has installed a bunch of trojaned binaries, including "/usr/local/bin/touch" binary. Unfortunately, there is a LaunchDaemon which runs the script periodically which contains the line "touch /some/file". That is run as root, so in a short time, the malware gets root access. And it immediately used this access to disable time machine and delete all the backups. A week later, user notices that a document is encrypted. And the time machine backups are gone, too. Oh no! the documents are lost unless they pay the ransom! --- You might notice that some people may consider the scenario unrealistic: What if the user uses command line a lot, and is used to running "sudo"? What if a malware social engineers user by popping up a fake dialog asking for user password? Are there other privilege escalation methods? How often does this happen anyway? You should make your own decisions, but hopefully you at least see what the people are concerned about.