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