Are there any security issues in using environment variables like this?
bash, environment-variables, security, unix
Solution
Short answer:
Assuming the user is able to run programs and code of her own choice anyway, you do not have to trust anything they feed you, including the environment. If the account is limited in some ways (no shell access, no write access to file systems that allow execution), that may change the picture, but as long as your scripts are only doing things the user could do herself, why protect against malicious interference?
Longer answer:
There are at least two separate issues to consider in terms of security problems:
- What and whom do we need to guard against?
- (closely related question: What can our program actually do and what could it potentially break?)
- How do we do that?
If and as long as your program is running under the user ID of the user starting the program and providing all the input (i.e., the only one who could mount any attack), there are only rare situations where it makes sense at all to harden the program against attacks. Anti-copy protection and sharing high-scores comes to mind, but that group of things is not just concerned with inputs, but probably even more so with stopping the user from reading code and memory. Hiding the code of a shell script without some kind of suid/sgid trickery is nothing I'd know how to do; the best I could think of would be obscuring the code.
In this situation, anything the user could trick the program into doing, they could do without the help of the tool, too, so trying to “protect” against attacks by this user is moot. Your description does not read as if you'd actually need any protection against attacks.
Assuming you do need protection, you simply cannot rely on environment variables – and if you fail to reset things like `LD_LIBRARY_PATH` and `LD_PRELOAD`, even calling tools with absolute paths like `/bin/id` or `/bin/ls` won't give you a reliable answer, unless that tool happens to be statically compiled. This is why `sudo` has `env_reset` enabled by default and why running suid programs has to ignore certain environment variables. Note that this means that your point that `TOOLS_PATH_LIBRARY` and `PATH` are equally trustworthy may be true in your situation, but is not necessarily true in other situations' border cases: a sysadmin may reset `PATH` for `sudo` usage, but let non-standard environment variables pass through.
As pointed out above, `argv[0]` (or its bash equivalent `${BASH_SOURCE[0]}`) is no more reliable than environment variables. Not only can the user simply make a copy or symlink of your original file; `execve` or bash's `exec -a foo bar` allows putting anything into `argv[0]`.
Problem
I'm writing a collection of utilities in `bash` that has a common library. Each script I write has to have a block of code that determines the path of the library relative to the executable. Not the actual code, but an example: ``` #!/bin/bash DIR="$( cd -P "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" . $DIR/../lib/utilities/functions ``` Instead of a preamble that tries to search for the library, I had the bright idea to use an environment variable to indicate the libraries location. ``` #!/bin/bash . $TOOLS_LIBRARY_PATH ``` I could use a wrapper program to set that environment variable, or I could set it in my own path. There may be better ways to organize a `bash` toolset, but question is: Can I trust my environment variables? This is one of those, I've-never-really-thought-about-it kind of questions. When programming in other languages, paths are used to find libraries, (e.g. `LD_LIBRARY_PATH`, `PYTHONPATH`, `PERLLIB`, `RUBYLIB`, `CLASSPATH`, `NODE_PATH`), but I've never had to stop and think about how that could be insecure. In fact, `LD_LIBRARY_PATH` has Why `LD_LIBRARY_PATH` is bad to discourage its use. The Ruby and Perl library path environment variables are ignored if their security mechanisms are invoked, `$SAFE` and `-T` (taint mode) respectively. My thoughts so far... - The user could set `TOOLS_PATH_LIBRARY` to a library of their choosing, but the utility will run under their uid. They could simply run their malicious library directly with `bash`. - My tools `sudo` some things. Someone could set their `TOOLS_PATH_LIBRARY` to something that takes advantage of this. But, the tools are not run via `sudo`, they only invoke `sudo` here and there. The user would have to be a `sudoer` in any case, they could just call `sudo` directly. - If I can't trust `TOOLS_PATH_LIBRARY`, then I can't trust `PATH`. All program invocations must use absolute paths. - I've seen shell programs use aliases for programs that are absolute, so that instead of calling `ls`, use a variable, like `LS=/bin/ls`. From what I've read, this is to protect against users redefining program defaults as aliases. See: PATH, functions and security. Bash scripting best practices. . - Perl's taint mode treats all environment variables as "tainted", which foreboding, which is why I'm trying to reason about the risks of environment. - It is not possible for one users to change another's environment, unless that user is root. Thus, I'm only concerned about a user changing their own environment to escalate privileges. See: Is there a way to change another process's environment variables? I've rubber ducked this into an answer of sorts, but I'm still going to post it, since it isn't a pat answer. Update: What are the security issues surrounding the use of environment variables to specify paths to libraries and executables?