PolicyKit: Changes to 'polkit-0-96'
David Zeuthen
david at kemper.freedesktop.org
Tue Apr 19 11:46:53 PDT 2011
New branch 'polkit-0-96' available with the following commits:
commit f664666137fb85c19b636a2e0bfd4de0e7d59b56
Author: Petr Mrázek <peterix at gmail.com>
Date: Wed Jul 14 02:59:12 2010 +0200
Bug 29051 â Configuration reload on every query
Set has_data to true after the data is loaded to prevent excessive
reloading of config files.
Signed-off-by: David Zeuthen <davidz at redhat.com>
commit 28e485cac449c8eb37c21eecb95f5fa125def9d4
Author: Dan Rosenberg <dan.j.rosenberg at gmail.com>
Date: Wed Mar 10 12:46:19 2010 -0500
Bug 26982 â pkexec information disclosure vulnerability
pkexec is vulnerable to a minor information disclosure vulnerability
that allows an attacker to verify whether or not arbitrary files
exist, violating directory permissions. I reproduced the issue on my
Karmic installation as follows:
$ mkdir secret
$ sudo chown root:root secret
$ sudo chmod 400 secret
$ sudo touch secret/hidden
$ pkexec /home/drosenbe/secret/hidden
(password prompt)
$ pkexec /home/drosenbe/secret/doesnotexist
Error getting information about /home/drosenbe/secret/doesnotexist: No such
file or directory
I've attached my patch for the issue. I replaced the stat() call
entirely with access() using F_OK, so rather than check that the
target exists, pkexec now checks if the user has permission to verify
the existence of the program. There might be another way of doing
this, such as chdir()'ing to the parent directory of the target and
calling lstat(), but this seemed like more code than necessary to
prevent such a minor problem. I see no reason to allow pkexec to
execute targets that are not accessible to the executing user because
of directory permissions. This is such a limited use case anyway that
this doesn't really affect functionality.
http://bugs.freedesktop.org/show_bug.cgi?id=26982
Signed-off-by: David Zeuthen <davidz at redhat.com>
commit 5d44f404809ab0bdf277c1f49387b5339d02122e
Author: David Zeuthen <davidz at redhat.com>
Date: Mon Apr 11 12:45:13 2011 -0400
pkexec: Avoid TOCTTOU problems with parent process
In a nutshell, the parent process may change its uid (either real- or
effective uid) after launching pkexec. It can do this by exec()'ing
e.g. a setuid root program.
To avoid this problem, just use the uid the parent process had when it
executed pkexec. This happens to be the same uid of the pkexec process
itself.
Additionally, remove some dubious code that allowed pkexec to continue
when the parent process died as there is no reason to support
something like that. Also ensure that the pkexec process is killed if
the parent process dies.
This problem was pointed out by Neel Mehta <nmehta at google.com>.
Signed-off-by: David Zeuthen <davidz at redhat.com>
commit 55e6f92e7340d57a66f83bd69bdf26454fdf7533
Author: David Zeuthen <davidz at redhat.com>
Date: Mon Apr 11 12:41:35 2011 -0400
Use polkit_unix_process_get_uid() to get the owner of a process
This avoids a TOCTTOU problem.
Signed-off-by: David Zeuthen <davidz at redhat.com>
commit 9a44af8ab67d09a2c08be29428b8fe32da809e99
Author: David Zeuthen <davidz at redhat.com>
Date: Mon Apr 11 12:41:00 2011 -0400
Make PolkitUnixProcess also record the uid of the process
This is needed to avoid possible TOCTTOU issues since a process can
change both its real uid and effective uid.
Signed-off-by: David Zeuthen <davidz at redhat.com>
commit 83a65f1255fc3eebfb4be1f80a5ab0b5f98eef7c
Author: David Zeuthen <davidz at redhat.com>
Date: Mon Apr 11 11:38:22 2011 -0400
PolkitUnixProcess: Clarify that the real uid is returned, not the effective one
On Linux, also switch to parsing /proc/<pid>/status instead of relying
on the st_uid returned by stat(2) to be the uid we want.
This was pointed out by Neel Mehta <nmehta at google.com>. Thanks!
Signed-off-by: David Zeuthen <davidz at redhat.com>
More information about the hal-commit
mailing list