questions about pkexec

[Dmitry V. Levin]

On Mon, Nov 30, 2009 at 11:53:46AM -0500, David Zeuthen wrote:
> On Sat, 2009-11-28 at 01:32 +0300, Vladislav Zavjalov wrote:
> > Is there a reason why pkexec is a suid root helper now,
> > not a client-mechanism pair (as proposed for such purposes
> > in the polkit manpage)?
> 
> Simply because there is not benefit of splitting this into a
> daemon/client - I mean, all that pkexec does is to exec a process after
> checking for authorization - it's really not a lot of code.

Well, there are some noticeable fundamental differences between these
approaches, and from security point of view these differences may have
more or less fatal consequences.  Here are most important differences:

- 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.

- 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).  But you don't run PAM stack
like sudo(8) does, so an executable launched by pkexec will inherit
caller's resource limits.  Consequences may vary.  For example, a low
RLIMIT_FSIZE value may cause unprepared privileged application to corrupt
system files.
A client/server model defines in details what exactly a client side can
send to its server side via connection (a unix domain socket in this case)
between them.

- Suid helper is built from some code.  It's really not a lot of code,
that's true, but in sufficiently aggressive environment even that
amount of code plus code of libraries it uses may pose a risk.

All these differences speak in favour of replacing suid root helpers with
more secure client/server implementations.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/polkit-devel/attachments/20091208/82363374/attachment.pgp