Introspection

[David Zeuthen]

On Sun, 2008-12-07 at 19:08 -0500, Colin Walters wrote:
> One thing that came up in the initial report is introspection.  Almost
> nothing explicitly allows it right now.  I see a few options:
> 
> 1) Have projects use rules of the form
>     <allow send_destination="org.freedesktop.Hal"
>                send_interface="org.freedesktop.DBus.Introspectable" />
> 2) Add rule syntax like: <allow introspect="org.freedesktop.Hal"/>,
> and add that to the config files
> 3) Blanket allow introspection as a global exception to the default-deny policy
> 
> Opinions?  Other options?  1) and 2) require updating almost
> everything, 3) requires another DBus release.

I'm looking at

https://bugs.freedesktop.org/show_bug.cgi?id=18948

for a small D-Bus system service in PolicyKit. The only interesting
things in /etc/dbus-1/system.d/org.freedesktop.PolicyKit.conf are

  <!-- Only polkituser can own the service -->
  <policy user="polkituser">
    <allow own="org.freedesktop.PolicyKit"/>
  </policy>

Now, I'd argue that one natural thing here is that this invocation *by
default* should allow any other process to send messages to *any*
interfaces for the name org.freedesktop.PolicyKit. That's the main point
of owning a name; that you can provide services through it (there's also
the special case of using the Name as a mutex; but typically you don't
handle messages / export objects on such a name).

I'm scratching my head trying to figure out what would be the problem
with requiring such a thing and what "security" we're try to add by
requiring the service developer to manually add such lines. Remember,
we're talking about the *defaults* here; people can still add their own
"deny all, then punch holes" policy to their config file (to use e.g.
"at_console" or "group membership" or whatever).

If it's because that we're afraid that developers will forget about
security (making him manually add interfaces will at least remind him)
and leave everything open, then that developer probably got bigger
problems to worry about (developing services that run in a system
context is not trivial and requires a lot attention to detail / security
anyway). So I'd argue we shouldn't even try. 

Also, it's problematic if we're adding bandaids like always allowing
access to certain standard interfaces (Introspectable, Peer,
Properties); it just makes it more complicated to figure out how to use
the <allow> and <deny> directives in the configuration files; it ain't
easy already.

Finally, with my distributor hat on, i think it's especially a problem
if we're breaking the world with this new D-Bus release; it's not really
realistic to require that all D-Bus system configuration files needs to
be revised (which is the current situation); some vendors may have
customers with custom stuff they can't fix.

Discuss.

      David