Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • D dbus
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 268
    • Issues 268
    • List
    • Boards
    • Service Desk
    • Milestones
  • Custom issue tracker
    • Custom issue tracker
  • Merge requests 36
    • Merge requests 36
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • dbusdbus
  • dbus
  • Issues
  • #11
Closed
Open
Issue created Dec 08, 2008 by Bugzilla Migration User@bugzilla-migration

nondeterministic denials for no-interface messages

Submitted by Colin Walters @walters

Assigned to Havoc Pennington

Link to original bug (#18961)

Description

Created attachment 20913 don't process deny rules if interface doesn't match

There is a flaw (or at least, problematic behavior) in the current policy logic that causes nondeterminism. This is not a security flaw per se, more of a reliability flaw because it causes denials where they were not intended. This flaw mirrors CVE-2008-0595 (http://lists.freedesktop.org/archives/dbus/2008-February/009401.html). The problem stems from rules of the form:

File A:

<policy context="default">
  <allow send_destination="com.foo.MyService"/>
</policy>

File B:

<policy context="default">
  <allow send_destination="org.foo.Bar"/>
  <deny send_interface="org.foo.Bar.Secure"/>
</policy>

This looks innocuous enough at first (as all these rules do); clearly the intent of the second rule is to lock down access to just part of org.foo.Bar. But it breaks the case of messages sent with no interface to the com.foo.MyService: depending on include ordering

The no-interface case happens in dynamic language scripts like Python typically.

Tracing the logic in policy.c, what happens when a message is sent with no interface is that we see the rule has an interface, then fall into the logic:

      if ((no_interface && rule->allow) ||
           (!no_interface && 
            strcmp (dbus_message_get_interface (message),
                    rule->d.send.interface) != 0))
        continue;

So we're processing a deny rule, with no interface, and this logic does not match. Thus we hit the rule, and the default becomes deny. If we happened to process the rules from the other file first, the message will be spuriously denied.

Patch 20913, "don't process deny rules if interface doesn't match":
dbus-policy.patch

Version: 1.5

Edited Dec 04, 2019 by Simon McVittie
Assignee
Assign to
Time tracking