questions about pkexec

[David Zeuthen]

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