Starting the kdbus discussions
Simon McVittie
simon.mcvittie at collabora.co.uk
Fri Jan 3 05:51:35 PST 2014
On 02/01/14 17:08, Lennart Poettering wrote:
> Well, it's generally not applications talking to other
> applications. It's mostly applications talking to desktop services. And
> those I believe should just come with PolicyKit hooks. I am pretty sure
> having apps talk to other apps is something a good sandbox should
> prohibit entirely.
I think I agree with Lennart here. What we've always told application
authors is that the session bus is not a security boundary; if that's no
longer true on your system, then I'm afraid the onus is on you to
prevent less-privileged processes from communicating with anything that
hasn't been audited to ensure that it can't be used to escalate
privileges (and to fix the fallout from this when a less-privileged
process is denied permission to do something that its author thought
would always be allowed).
For instance, if you can do arbitrary writes to dconf, I'm pretty sure
at least one application or session service has a dconf key of the form
"when event foo happens, run this command". That's an easy privilege
escalation vector. Disclosing file contents by pointing a configuration
key towards a file you can't read is probably also fairly easy.
It would probably make sense to have some sort of "second-class citizen"
scheme in which "trusted" apps can talk to nearly everything,
"untrusted" apps can only talk to what they really need, and "trusted"
apps are gradually enhanced so they can be run as "untrusted". It would
be reasonable to include "trusted" apps in Ubuntu, but refuse to host
apps on behalf of third parties unless they are "untrusted".
(Analogous: imagine you have a Unix system where system services all run
as root with full capabilities, and you want to turn it into what we
have today, with a minority of root-privileged, fully-capable services.)
S
More information about the dbus
mailing list