Hi, I've recently been looking at the security properties of various setuid executables, many of which use PAM for authentication. What is PAM's policy on the extent to which modules may trust the process' execution environment, particularly environment variables? I can see three options for a consistent policy: 1) PAM is considered safe to use in a setuid process, even if the environment has not been "cleaned". Modules must not use libraries or execute helper programs that can be adversely affected by environment variables. 2) PAM is only considered safe to use in a setuid process if the environment has been "cleaned" against a whitelist. Modules may use any library, or execute any helper program; privileged processes that are run with a potentially-attacker-controlled environment must "clean" it before using PAM. If the process intends to use the original environment later, it can save a copy before cleaning it, and pass that copy to execle or similar. 3) There is some mechanism that can/should be used in modules to decide whether the process in which they are hosted is privileged or not. If it is, they must ensure that they ignore environment variables; if it is not, they may obey environment variables. Which of these policies do the PAM maintainers consider it to have? For some examples of setuid executables which behave defensively and clear the environment (i.e. behaving as if the policy is (2), but also OK for either of the others), see polkit's pkexec[1] and polkit-agent-helper-1[2]. [1] http://cgit.freedesktop.org/polkit/tree/src/programs/pkexec.c (saves the old environment first, and may pass a filtered subset to the executed program) [2] http://cgit.freedesktop.org/polkit/tree/src/polkitagent/polkitagenthelper-pam.c#n76 (clears the environment altogether) For examples of setuid executables which do not clear the environment (i.e. assuming that the policy is (1)), see most su implementations. Here are some examples of things modules in these processes can't be allowed to do without special precautions if policy (1) is in effect: * trust executables in $PATH * trust $IFS not to be something that will confuse a shell script * connect to $DBUS_SESSION_BUS_ADDRESS or $DBUS_SYSTEM_BUS_ADDRESS (either of which can contain a command to start a "tunnel") * load code from $PERL5LIB, $PYTHONPATH, $PYTHONHOME etc. * trust UTF-8 input in conjunction with PERLIO=:utf8 * trust that $TZDIR is non-malicious * connect to $DISPLAY? (if the X11 protocol is such that connecting to a socket specified by an attacker can cause bad things to happen) * (etc.) * execute an external command that does any of those sudo(1) has a long list of variables that are considered unsafe. If PAM doesn't have a policy for this, I would personally advocate policy (2), as recommended by <http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/environment-variables.html>. I do notice that this would break use of pam_xauth in setuid executables, although it isn't clear to me whether that would make sense anyway. For the DBUS_* variables this was reported as CVE-2012-3524, and mitigated in libdbus and GDBus by distrusting environment variables if getuid() != geteuid() (so, a partial implementation of policy (3), but perhaps not with the same mechanism to detect privilege that you'd choose). I'm mainly interested in environment variables and setuid at the moment, but similar considerations apply to other bits of process environment that are inherited from a parent that can be less privileged (most notably, current working directory), and to mechanisms for privilege escalation other than setuid (setgid, Linux filesystem capabilities, etc.). Opinions? Regards, Simon _______________________________________________ Pam-list mailing list Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list
