[apparmor] DBus rule syntax for subject and peer components

[Jamie Strandboge]

On 06/11/2013 08:46 PM, Seth Arnold wrote:
> On Mon, Jun 10, 2013 at 06:44:13PM -0700, Tyler Hicks wrote:
>> To start us off, here's the profile using the current DBus syntax. It is
>> complex, but it uses all of the DBus accesses (send, receive, and
>> acquire) and it is representative of what a real profile may look like.
> 
> Thanks for this. These are all less readable than I'd expected, and as
> you pointed out, when we used com.example.foo it was too easy to overlook
> the complexity we've got here.
> 
> So, here's a first shot at Proposal #4:
> 
> I'm having trouble coming up with a BNF-style description of my newest
> proposal, which doesn't bode well for implementing it, but I hope
> factoring out common pieces of policy that "float up" makes some sense.
> 
> First, move the permission next to the 'dbus' keyword; this makes it
> easier to spot, groups like-permissions, and allows bus= handling to be
> very similar to the other keywords. Next, more brackets! If a portion of
> a rule can be 'factored' out of several rules, pull it 'up', and push the
> specifics 'down'.
> 
> Here's the example gnome-screensaver; I've converted the original 16
> lines into 50 lines, so it isn't exactly space-saving. There's no reason
> for the newlines 'within' a block except to keep it from going longer
> than 80 chars, so it could be much shorter, but I think this is how I
> would want to write the rules.
> 
> /usr/bin/gnome-screensaver {
>   # Ignore file and accessibility bus access for this excercise
>   file,
>   dbus bus=accessibility,
> 
>   # sarnold> I think we could remove this entirely; for any bus with
>   # bus= rules later on, add this rule implicitly. We can do this with
>   # any of the proposals..
>   # Talks to system and session buses
>   # dbus bus={system,session} peer=(name=org.freedesktop.DBus) (send receive),
> 
>   dbus send {
>     bus=system {
>       peer {
>         name=org.freedesktop.ConsoleKit
>         path=/org/freedesktop/ConsoleKit/Manager
>         interface=org.freedesktop.ConsoleKit.Manager
>       },
>       peer name=org.freedesktop.Accounts {
>         {
>           path=/org/freedesktop/Accounts
>           interface=org.freedesktop.Accounts
>         },
>         {
>           path=/org/freedesktop/Accounts/User*
>           interface=org.freedesktop.DBus.Properties
>         },
>       }
>     }
>     bus=session {
>       peer {
>         name=org.gnome.SessionManager
>         path=/org/gnome/SessionManager/Presence
>         interface=org.freedesktop.DBus.Properties
>       },
>       peer {
>         path=/org/gtk/vfs/mounttracker
>         interface=org.gtk.vfs.MountTracker
>       },
>       peer {
>         name=org.gnome.Shell
>         path=/org/gnome/Shell
>         interface=org.freedesktop.DBus.Properties
>       },
>     }
>   }
> 
>   # Receives messages on the session bus
>   dbus acquire bus=session {
>     subj name=org.gnome.ScreenSaver,
>   }
> 
>   dbus receive bus=session {
>     subj path=/org/gnome/ScreenSaver {
>       interface=org.freedesktop.DBus.Properties,
>       interface=org.gnome.ScreenSaver {
>         peer label=/usr/bin/gnome-settings-daemon,
>         peer name=com.canonical.indicator.session,
>       }
>     }
>   }
> }
> 

I really don't like Proposal #4 (no offense, I also really don't like 
my own proposal #2). I think I don't like it because all the nested 
brackets seem quite messy (especially when considering child and 
sibling profiles) and, like John mentioned, nesting peer under subject 
doesn't feel right. Furthermore, I don't like the feel of grouping 
things under a single access. Granted, something like this:

  /** r,
  /tmp/** w,

isn't totally conceptually different than:

  dbus receive {
    bus=session
  }
  dbus send {
    bus=session
    peer name=org.freedesktop.Accounts
  }

but it isn't nearly as intuitive as a policy author where I tend to 
look at the file path, capability, subj, peer, etc first, and then 
consider the access, but Proposal #4 really turns this around in an 
awkward way for me (note, I don't care that the access is first or 
not-- I just object to nesting under the access). Currently, I am able 
to look an audit message and write a corresponding dbus rule. This is 
preserved in Proposal #3.


> I think the language I've proposed could be used in either compressed or
> expanded modes. The last block could also be written like this:
> 
> dbus receive bus=session subj path=/org/gnome/ScreenSaver interface=org.freedesktop.DBus.Properties,
> dbus receive bus=session subj path=/org/gnome/ScreenSaver interface=org.gnome.ScreenSaver peer label=/usr/bin/gnome-settings-daemon,
> dbus receive bus=session subj path=/org/gnome/ScreenSaver interface=org.gnome.ScreenSaver peer name=com.canonical.indicator.session,
> 
> But, the fact that describing this thing in a BNF is difficult might
> make implementing it too expensive.
> 
> 
> So here's proposal #3 with linewraps where I think I'd want to put them to
> try to make them long-term legible. It's still shorter than my "factoring"
> approach above, but the density still makes my eyes glaze over a bit. :)
> 
> 
> /usr/bin/gnome-screensaver {
>   # Ignore file and accessibility bus access for this excercise
>   file,
>   dbus bus=accessibility,
> 
>   # Talks to system and session buses
>   dbus bus={system,session} peer=(name=org.freedesktop.DBus) (send receive),
> 
>   # Sends messages on the system bus
>   dbus bus=system
>     peer=(name=org.freedesktop.ConsoleKit
>           path=/org/freedesktop/ConsoleKit/Manager
>           interface=org.freedesktop.ConsoleKit.Manager) send,
>   dbus bus=system
>     peer=(name=org.freedesktop.Accounts
>           path=/org/freedesktop/Accounts
>           interface=org.freedesktop.Accounts) send,
>   dbus bus=system
>     peer=(name=org.freedesktop.Accounts
>           path=/org/freedesktop/Accounts/User*
>           interface=org.freedesktop.DBus.Properties) send,
> 
>   # Receives messages on the session bus
>   dbus bus=session subj=(name=org.gnome.ScreenSaver) acquire,
>   dbus bus=session
>     subj=(path=/org/gnome/ScreenSaver
>           interface=org.freedesktop.DBus.Properties) receive,
>   # Be selective because the Lock method is mediated by these rules
>   dbus bus=session
>     subj=(path=/org/gnome/ScreenSaver
>          interface=org.gnome.ScreenSaver)
>     peer=(label=/usr/bin/gnome-settings-daemon) receive,
>   dbus bus=session
>     subj=(path=/org/gnome/ScreenSaver
>           interface=org.gnome.ScreenSaver)
>     peer=(name=com.canonical.indicator.session) receive,
> 
>   # Sends messages on the session bus
>   dbus bus=session
>     peer=(name=org.gnome.SessionManager
>           path=/org/gnome/SessionManager/Presence
>           interface=org.freedesktop.DBus.Properties) send,
>   dbus bus=session
>     peer=(path=/org/gtk/vfs/mounttracker
>     interface=org.gtk.vfs.MountTracker) send,
>   dbus bus=session
>     peer=(name=org.gnome.Shell
>           path=/org/gnome/Shell
>           interface=org.freedesktop.DBus.Properties) send,
> }
> 

I think the multiline approach for Proposal #3 is not a bad idea, but 
also not a blocker on pushing the single line approach now, and 
bringing multiline later.

Talking to John and Tyler today, I too am not opposed to using blocking 
mechanisms instead which I think captures some of what Seth is going 
for, and looks cleaner. Eg:

dbus [<bus>] [subj { <subject> } ] [acquire],
dbus [<bus>] [subj { <subject> } ] [peer { <peer> }] [send | receive],

/usr/bin/gnome-screensaver {
  # Ignore file and accessibility bus access for this excercise
  file,
  dbus bus=accessibility,

  # Talks to system and session buses
  dbus bus={system,session} peer { name=org.freedesktop.DBus } (send receive),

  # Sends messages on the system bus
  dbus bus=system peer { name=org.freedesktop.ConsoleKit path=/org/freedesktop/ConsoleKit/Manager interface=org.freedesktop.ConsoleKit.Manager } send,
  dbus bus=system peer { name=org.freedesktop.Accounts path=/org/freedesktop/Accounts interface=org.freedesktop.Accounts } send,
  dbus bus=system peer { name=org.freedesktop.Accounts path=/org/freedesktop/Accounts/User* interface=org.freedesktop.DBus.Properties } send,

  # Receives messages on the session bus
  dbus bus=session subj { name=org.gnome.ScreenSaver } acquire,
  dbus bus=session subj { path=/org/gnome/ScreenSaver interface=org.freedesktop.DBus.Properties } receive,
  # Be selective because the Lock method is mediated by these rules
  dbus bus=session subj { path=/org/gnome/ScreenSaver interface=org.gnome.ScreenSaver } peer { label=/usr/bin/gnome-settings-daemon } receive,
  dbus bus=session subj { path=/org/gnome/ScreenSaver interface=org.gnome.ScreenSaver } peer { name=com.canonical.indicator.session } receive,

  # Sends messages on the session bus
  dbus bus=session peer { name=org.gnome.SessionManager path=/org/gnome/SessionManager/Presence interface=org.freedesktop.DBus.Properties } send,
  dbus bus=session peer { path=/org/gtk/vfs/mounttracker interface=org.gtk.vfs.MountTracker } send,
  dbus bus=session peer { name=org.gnome.Shell path=/org/gnome/Shell interface=org.freedesktop.DBus.Properties } send,
}

Personally, I still prefer Proposal #3 with the potential to
go multi-line in the future. 

-- 
Jamie Strandboge                 http://www.ubuntu.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20130612/639bf3cb/attachment.pgp>