Bug 13742

Summary:	make it harder to spy the password and abuse privileges from PK processes
Product:	PolicyKit	Reporter:	Martin Pitt <martin.pitt>
Component:	libpolkit	Assignee:	David Zeuthen (not reading bugmail) <zeuthen>
Status:	RESOLVED INVALID	QA Contact:	David Zeuthen (not reading bugmail) <zeuthen>
Severity:	normal
Priority:	medium	CC:	bugs, pachoramos1
Version:	unspecified
Hardware:	All
OS:	All
URL:	https://wiki.ubuntu.com/DesktopTeam/Specs/PolicyKitIntegration
Whiteboard:
i915 platform:		i915 features:
Attachments:	disable ptrace() for polkit-gnome-manager disable ptrace() for apps using libpolkit

Description Martin Pitt 2007-12-19 15:48:59 UTC

Recently we had a small discussion about how we can make it a little harder to silently pull passwords or abuse privileges from PolicyKit processes (and others, like ssh or gnupg). The main source of grief is that a local trojan can easily ptrace() a running gnome-system-tools/gnome-mount/ssh/etc. process to grab the password from memory or use the target process' PK privileges.

By doing prctl(SET_DUMPABLE, 0), a process can stop the possibility of attaching gdb. It also inhibits core dumps to avoid writing passwords and other sensitive things to the disk.

This measure by itself is of course not the solution to all problems, and it's easy to circumvent (race condition, spoofing it, etc.), but it's a small and unintrusive first line of defence.

Comment 1 Martin Pitt 2007-12-19 15:51:30 UTC

Created attachment 13237 [details] [review]
disable ptrace() for polkit-gnome-manager

This disables ptrace() for polkit-gnome-manager.

Comment 2 Martin Pitt 2007-12-19 16:10:16 UTC

Unfortunately there is no client library for wrapping the 'authenticate me' call yet, that happens with a direct dbus call (at least in gnome-mount).

If PK ever gets a client API for that, this function should call prctl(PR_SET_DUMPABLE, 0) as well, so that the app stops being ptrace()able and core dumpable as soon as it keeps a secret. This stops other processes from silently connecting and abusing the privilege. (Again, this is a bandaid, no rock solid solution).

Until this happens, it could be put into the libpolkit library constructor, so that apps using it are always protected. This is more than necessary and also doesn't apply to e. g. gnome-mount (which doesn't link against libpolkit.so), but at least it avoids patching a lot of apps like all the gnome-system-tools apps.

Comment 3 Martin Pitt 2007-12-19 16:23:37 UTC

Created attachment 13239 [details] [review]
disable ptrace() for apps using libpolkit

This is the bandaid patch for libpolkit users, as described in the previous comment. I'm not entirely happy about doing it this way, but without an official function to get a privilege this is a best-effort patch.

Comment 4 Florian Steinel 2007-12-26 11:20:04 UTC

a look at gnome-keyring would help?
http://svn.gnome.org/viewvc/gnome-keyring/trunk/
http://svn.gnome.org/viewvc/gnome-keyring/trunk/library/gnome-keyring-memory.c?view=markup

Other useful links:
Private Memory Lock http://bugzilla.gnome.org/show_bug.cgi?id=484976

Comment 5 Florian Steinel 2007-12-26 11:30:19 UTC

additional link:
http://svn.gnome.org/viewvc/gnome-keyring/trunk/common/gkr-secure-memory.c?view=markup

Comment 6 Martin Pitt 2007-12-27 00:59:35 UTC

mlock() should be done in addition, of course (that's best practice for passwords, too). Indeed it doesn't do that yet.

Comment 7 Martin Pitt 2008-01-15 14:30:26 UTC

Comment on attachment 13237 [details] [review]
disable ptrace() for polkit-gnome-manager

With 0.7 the patch to pk-gnome is not necessary any more, since it links against libpolkit and thus already gets the ptrace() disabling from the other patch.

Comment 8 Martin Pitt 2009-10-01 23:32:10 UTC

Obsolete with pk-1, this needs a new approach. Closing for now.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.