1. 26 Feb, 2008 1 commit
    • Holger Macht's avatar
      avoid reliance on DT_REG so we work on reiserfs as well · 0b59d3e7
      Holger Macht authored
      (with minor fixes from davidz for avoiding memory leaks)
      Recently I wondered why PolicyKit (especially polkit-auth) does not work
      on my system. While debugging, I noticed that the corresponding code works
      in my home directory, but not in the root filesystem.
      readdir() and its d_type are the culprits. Quoting the readdir manpage:
      Other than Linux, the d_type field is available mainly only on BSD
      systems.  This field makes it possible to avoid the expense of calling
      stat() if further actions depend on the type of the file.
      Filesystems may fill DT_UNKNOWN into this field, which reiserfs does, so
      call stat instead, which always does the right thing.
      Signed-off-by: Holger Macht's avatarHolger Macht <hmacht@suse.de>
  2. 07 Dec, 2007 5 commits
    • David Zeuthen's avatar
      fix typo in docs · 2c331fe6
      David Zeuthen authored
    • David Zeuthen's avatar
    • David Zeuthen's avatar
      add additional checks when using strtoul · 46005c49
      David Zeuthen authored
      Pointed out by Martin Pitt <martin.pitt@ubuntu.com>.
    • David Zeuthen's avatar
      add constraints for exe and SELinux context when granting an authorization · a8e46ceb
      David Zeuthen authored
      The way it works is that added constraints now look like this
      or if not using SELinux like this
      This is a bit icky to implement for mechanisms, like HAL, running as
      an unprivileged user. The problem is that we can't resolve the symlink
      /proc/pid/exe. On the other hands such mechanisms has the
      authorization org.freedesktop.policykit.read already. So use that.
      Note that this is what some people call snake-oil. The reason is in the
      docs for polkit_sysdeps_get_pid_for_exe(); copying it here so I can point
      people to this commit in the future
        Get the name of the binary a given process was started from.
        Note that this is not necessary reliable information and as such
        shouldn't be relied on 100% to make a security decision. In fact,
        this information is only trustworthy in situations where the given
        binary is securely locked down meaning that 1) it can't be
        ptrace(2)'d; 2) libc secure mode kicks in (e.g LD_PRELOAD won't
        work); 3) there are no other attack vectors (e.g. GTK_MODULES, X11,
        CORBA, D-Bus) to patch running code into the process.
        In other words: the risk of relying on constraining an authorization
        to the output of this function is high. Suppose that the program
        /usr/bin/gullible obtains an authorization via authentication for
        the action org.example.foo. We add a constraint to say that the
        gained authorization only applies to processes for whom
        /proc/pid/exe points to /usr/bin/gullible. Now enter
        /usr/bin/evil. It knows that the program /usr/bin/gullible is not
        "securely locked down" (per the definition in the above
        paragraph). So /usr/bin/evil simply sets LD_PRELOAD and execs
        /usr/bin/gullible and it can now run code in a process where
        /proc/pid/exe points to /usr/bin/gullible. Thus, the recently gained
        authorization for org.example.foo applies. Also, /usr/bin/evil could
        use a host of other attack vectors to run it's own code under the
        disguise of pretending to be /usr/bin/gullible.
        Specifically for interpreted languages like Python and Mono it is
        the case that /proc/pid/exe always points to /usr/bin/python
        resp. /usr/bin/mono. Thus, it's not very useful to rely on that the
        result for this function if you want to constrain an authorization
        to e.g. /usr/bin/tomboy or /usr/bin/banshee.
      However. Once we have a framework for running secure desktop apps this
      will start to make sense. Such a framework includes securing X (using
      e.g. XACE with SELinux) and making the UI toolkit secure as well. It's
      a lot of work.
      Until then these constraints at least makes it harder to for malicious
      apps to abuse PolicyKit authorizations gained by other users.
    • David Zeuthen's avatar
      use strlen to avoid writing garbage at the end of the test auth file · 5ea38976
      David Zeuthen authored
      While this seems like a grave bug it is not. First, this only affects
      the test cases and the file is guaranteed to be zero terminated before
      the garbage anyway.
  3. 06 Dec, 2007 2 commits
  4. 05 Dec, 2007 1 commit
    • David Zeuthen's avatar
      don't require .policy files for auth lookups · ea7da4ea
      David Zeuthen authored
      With this change, 'make check' now works even when PolicyKit isn't
      installed (as it should). Before this change it failed because the
      .policy files for org.freedesktop.policykit.read and .grant was not
  5. 30 Nov, 2007 3 commits
  6. 29 Nov, 2007 2 commits
  7. 28 Nov, 2007 1 commit
  8. 25 Nov, 2007 2 commits
  9. 24 Nov, 2007 1 commit
  10. 22 Nov, 2007 1 commit
  11. 21 Nov, 2007 2 commits
  12. 20 Nov, 2007 4 commits
  13. 18 Nov, 2007 1 commit
  14. 17 Nov, 2007 3 commits
  15. 12 Nov, 2007 4 commits
  16. 11 Nov, 2007 6 commits
  17. 10 Nov, 2007 1 commit
    • David Zeuthen's avatar
      split utility bits into a private statically linked library · cd68aa0a
      David Zeuthen authored
      getting closer...
      $ grep glib *.c
      polkit-authorization.c:#include <glib.h>
      polkit-authorization-db.c:#include <glib.h>
      polkit-authorization-db-dummy.c:#include <glib.h>
      polkit-config.c:#include <glib.h>
      polkit-context.c:#include <glib.h>
      polkit-sysdeps.c:#include <glib.h>