-
David Zeuthen authored
The way it works is that added constraints now look like this scope=always:action-id=org.pulseaudio.acquire-high-priority:when=1197004781:auth-as=0:constraint=local:constraint=active:constraint=exe%3A%2Fusr%2Fbin%2Fpulseaudio:constraint=selinux_context%3Asystem_u%3Asystem_r%3Aunconfined_t or if not using SELinux like this scope=always:action-id=org.freedesktop.hal.storage.mount-fixed:when=1197008218:auth-as=0:constraint=local:constraint=active:constraint=exe%3A%2Fusr%2Fbin%2Fgnome-mount 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.
a8e46ceb