[apparmor] DBus rule syntax for subject and peer components

Jamie Strandboge jamie at canonical.com
Tue Jun 11 20:25:43 UTC 2013


On 06/10/2013 08:44 PM, Tyler Hicks wrote:

> There are a few changes needed for the new syntax:
> 
>  1. dest= will be changed to name= so that it can identify either the subject's
>     or the peer's connection name without causing confusion
>  2. method= will be changed to member= so that it can identify either methods
>     or signals without causing confusion

+1

>  3. There needs to be a way to specify both the subject and peer's address
>     components

...

> 
> * Proposal 1 - Leveraging the meaning of arrows
> 
> Based on Seth's suggestion[2]. It eliminates the send and receive permissions
> and uses arrows to indicate the how messages can flow between two different
> DBus connections. The acquire permission and syntax is not changed.
> 
> dbus [<bus>] [<subject>] [acquire],
> dbus [<bus>] [<subject>] [-> | <- | <->] [<peer>], 
> 
> /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} name=org.freedesktop.DBus (send receive),
> 
>   # Sends messages on the system bus
>   dbus bus=system -> name=org.freedesktop.ConsoleKit path=/org/freedesktop/ConsoleKit/Manager interface=org.freedesktop.ConsoleKit.Manager,
>   dbus bus=system -> name=org.freedesktop.Accounts path=/org/freedesktop/Accounts interface=org.freedesktop.Accounts,
>   dbus bus=system -> name=org.freedesktop.Accounts path=/org/freedesktop/Accounts/User* interface=org.freedesktop.DBus.Properties,
> 
>   # Receives messages on the session bus
>   dbus bus=session name=org.gnome.ScreenSaver acquire,
>   dbus bus=session path=/org/gnome/ScreenSaver interface=org.freedesktop.DBus.Properties <-,
>   # Be selective because the Lock method is mediated by these rules
>   dbus bus=session path=/org/gnome/ScreenSaver interface=org.gnome.ScreenSaver <- label=/usr/bin/gnome-settings-daemon,
>   dbus bus=session path=/org/gnome/ScreenSaver interface=org.gnome.ScreenSaver <- name=com.canonical.indicator.session,
> 
>   # Sends messages on the session bus
>   dbus bus=session -> name=org.gnome.SessionManager path=/org/gnome/SessionManager/Presence interface=org.freedesktop.DBus.Properties,
>   dbus bus=session -> path=/org/gtk/vfs/mounttracker interface=org.gtk.vfs.MountTracker,
>   dbus bus=session -> name=org.gnome.Shell path=/org/gnome/Shell interface=org.freedesktop.DBus.Properties,
> }
> 

I really want to like the arrows as they work nicely in some
situations, but am having a hard time with it. In particular, the
trailing '<-' seems quite awkward to me:

  dbus bus=session path=/org/gnome/ScreenSaver interface=org.freedesktop.DBus.Properties <-,

Like John, I don't like the inconsistency with acquire. I also am not
comfortable with how send rules resemble exec transitions.

> * Proposal 2 - Place the access between the subject and peer
> 
> Based on Jamie's "--" suggestion[3]. It moves the access information next to
> the subject, because the access is always applied to the subject. The acquire
> permission and syntax is not changed.
> 
> dbus [<bus>] [<subject>] [acquire],
> dbus [<bus>] [<subject>] [(send | receive)] [-- <peer>],
> 
> /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} name=org.freedesktop.DBus (send receive),
> 
>   # Sends messages on the system bus
>   dbus bus=system send -- name=org.freedesktop.ConsoleKit path=/org/freedesktop/ConsoleKit/Manager interface=org.freedesktop.ConsoleKit.Manager,
>   dbus bus=system send -- name=org.freedesktop.Accounts path=/org/freedesktop/Accounts interface=org.freedesktop.Accounts,
>   dbus bus=system send -- name=org.freedesktop.Accounts path=/org/freedesktop/Accounts/User* interface=org.freedesktop.DBus.Properties,
> 
>   # Receives messages on the session bus
>   dbus bus=session acquire name=org.gnome.ScreenSaver,
>   dbus bus=session path=/org/gnome/ScreenSaver interface=org.freedesktop.DBus.Properties receive,
>   # Be selective because the Lock method is mediated by these rules
>   dbus bus=session path=/org/gnome/ScreenSaver interface=org.gnome.ScreenSaver receive -- label=/usr/bin/gnome-settings-daemon,
>   dbus bus=session path=/org/gnome/ScreenSaver interface=org.gnome.ScreenSaver receive -- name=com.canonical.indicator.session,
> 
>   # Sends messages on the session bus
>   dbus bus=session send -- name=org.gnome.SessionManager path=/org/gnome/SessionManager/Presence interface=org.freedesktop.DBus.Properties,
>   dbus bus=session send -- path=/org/gtk/vfs/mounttracker interface=org.gtk.vfs.MountTracker,
>   dbus bus=session send -- name=org.gnome.Shell path=/org/gnome/Shell interface=org.freedesktop.DBus.Properties,
> }
> 

I'm 'ok' with this, but, again like John, I don't like how where bus is
in relation to the local address. The implied <local> -- <remote> feels
messier than it needs to be.

> * Proposal 3 - Grouping of subject and peer address components
> 
> Based on Steve's suggestion[4] and refined by Jamie[5]. It groups the
> connection attributes together based on whether it is the subject's connection
> attributes or the peer's.
> 
> 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,
> }
> 

I prefer Proposal 3 over the others. It is somewhat more verbose, but
not appreciably so over other syntaxes and I like how we are very
explicit with the rules (and thus prefer to use subj= still). I could
live with subject as implied like John said.

So for completeness, I previously suggested a slight variation on
Proposal 3 since the two '='s in close proximity look slightly odd:
  dbus bus=session peer=(name=org.gnome.SessionManager path=...


The following variation accounts for this:

dbus [<bus>] [subj(<subject>)] [acquire],
dbus [<bus>] [subj(<subject>)] [peer(<peer>)] [send | receive],

/usr/bin/gnome-screensaver {
  ...

  # Talks to system and session buses
  dbus bus={system,session} peer(name=org.freedesktop.DBus) (send receive),
  ...
  dbus bus=session subj(path=/org/gnome/ScreenSaver interface=org.gnome.ScreenSaver) peer(label=/usr/bin/gnome-settings-daemon) receive,
}


I do think is looks slightly prettier, but am uncomfortable with how it
is inconsistent with other multi-valued sets. My preference is still
Proposal 3.


-- 
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/20130611/604f31fb/attachment.pgp>


More information about the AppArmor mailing list