Google leaves your Chrome passwords unprotected to promote security. (article)
Google doesn't secure stored passwords, stating that it does not want
"to provide users with a false sense of security and encourage risky
behavior." Schuh's argument is that if a would-be attacker had access
to a user's machine then "the game was lost," as there would be "too
many vectors for [the attacker] to get what he wants."
This is not a security risk at all, because you can always only set environment variables for your current environment (e.g. current Bash session) and, using the export
command, its child environments (scripts you launch, subshells, etc.). It's impossible to escalate an environment variable created or modified into the parent environment. This includes that it's impossible for regular users to make system-wide changes, of course.
So the only environment that would be affected if you run export LD_LIBRARY_PATH=...
is your current shell and any subshells of it you might spawn later. Let's say you change the lookup path to include infected libraries at the beginning i.e. with the highest priority. Then you run an executable that loads one of the infected libs without even knowing. What happens now?
You have malicious code (from the infected library) running under your own user account with regular non-admin privileges. This might sound bad, but actually... so what? It runs with regular user privileges which again means it can not affect the entire system. By the way, directly running an executable with the same malicious code would have been much easier than modifying the library lookup path and waiting for a normal executable to load it.
Conclusion: A regular user can only modify their own library lookup path, which means they can also only load those libraries themselves under their regular user account with regular non-system-wide privileges. That said, it makes no difference whether they force loading an infected library or directly run an infected executable. You would gain absolutely nothing if that environment variable could not be overridden by users.
PS: There are also executables which have the setuid or setgid flag set, which means they will not run as the user/group of the one who runs them, but of the one who owns them. For example the sudo
executable is owned by root and has the setuid flag set, which means it always runs as root when executed. For security reasons, the $LD_LIBRARY_PATH
variable is ignored by executables with one of the setuid/setgid flags set to make sure that the regular user can not make an executable running with root privileges to load arbitrary libraries.
(Thanks to @Rinzwind for pointing this out!)
Best Answer
If an application doesn't require root to install, then the application is in fact "safer" (I quoted safer because, in general, an application can still be harmful if you don't know what it does whether you used sudo or not. e.g. Maybe it will sniff around your home directory and start uploading some confidential data, and you wouldn't need root access for that).
What you quoted means that you can unpack the game anywhere you want and start using it directly. Since your home directory is yours, then unpacking in your home directory does not require sudo.
Since you installed the game without
sudo
, then that just means the game doesn't need access to any of the system directories (i.e. safer).