On Tue, 2009-12-08 at 02:37 +0300, Dmitry V. Levin wrote: > - Presence of a setuid root executable that could be launched by > regular unprivileged users poses a risk by fact of its existence. > Recent history of the Linux kernel vulnerabilities gives a few > examples how such executables could be used to exploit kernel > flaws (see e.g. CVE-2009-1527, CVE-2009-1337). There are no > warranty that all kernel bugs of this kind have been found and > plugged forever. In other words, this deficiency of setuid > executables has no fix.
You can say exactly the same about the IPC mechanism for client/server - e.g. buffer overflows in libdbus.so. > - An attacker can influence behaviour of an executable in more various > ways in case when it was launched by a suid helper. In pkexec, you > try to secure privileged executable by closing non-standard descriptors > and filtering process environment (but still allow callers to pass PATH > and SHELL which is very risky -- imagine what would happen if a privileged > executable was going to execute something). We close all fds and only pass on these environment variables LANG LANGUAGE LC_ALL LC_MESSAGES SHELL TERM We could validate the contents of these environment variables - do you have any attack vectors in mind that people could abuse if we didn't? Do you know if su(1) and sudo(8) validates such variables? > But you don't run PAM > stack like sudo(8) does, so an executable launched by pkexec will inherit > caller's resource limits. It's a good point that we need to run the "open session" part of PAM stack - and, FWIW, limits is only one aspect of setting up the session. FWIW, I just added that, see http://cgit.freedesktop.org/PolicyKit/commit/?id=84958d3707ff43e8b8bda3fc0f669966db683f67 Btw, you are wrong about sudo(8) (and su(1) for that matter) - the spawned privileged process does indeed inherit the POSIX limits that applies to the spawning process: (unfortunately I got the comment wrong in the commit - see the next commit for the fix) $ ulimit -t unlimited $ su - Password: # ulimit -t unlimited # logout $ ulimit -t 1000 $ ulimit -t 1000 $ su - Password: # ulimit -t 1000 I don't know if it's supposed to work this way - maybe this is just a quirk with the Fedora configuration or version of pam_limits.so - or maybe it's a bug in sudo(8) or su(1). I left a TODO in the pkexec.c sources to investigate further. So on my system... > Consequences may vary. For example, a low > RLIMIT_FSIZE value may cause unprepared privileged application to > corrupt system files. ... applies to sudo(8) and su(1) too. Either way, we do the same thing as sudo(8) and su(1) now. David _______________________________________________ polkit-devel mailing list polkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/polkit-devel
