[apparmor] DBus rule syntax for subject and peer components

Tyler Hicks tyhicks at canonical.com
Tue Jun 11 21:41:03 UTC 2013


This was a good exercise because none of the proposals were mine and I
had to try to understand other people's proposals and think a bit like
them.

On 2013-06-10 18:44:13, Tyler Hicks wrote:
> * 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,
> }

This one was easy to understand and felt pretty natural.

As others have mentioned, the acquire rule asymmetry really sticks out.
We could replace 'acquire' with a symbol to fit in better with the send
and receive arrows, but nothing jumps out at me while looking at my
keyboard.

How about "--"? It is not very intuitive...

As it currently stands, I like Proposal 1 the second best. I don't have
any big gripes with it, I just don't love it.

> 
> * 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,
> }

This one didn't click for me. The -- just doesn't show up in useful
locations.

I expect that send rules will typically not have any subject components.
This is because the connection name will be unpredictable. The process
may simply not bind to a well known name or it may lose its well known
name (in which case you'd probably still want its messages to go
through). So, the left side of the -- will mostly be empty for send
rules.

I also don't like having to search for the access in the situations
where there is a subject address component and a peer address component.

As it currently stands, I like Proposal 2 the least.

> 
> * 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,
> }

This one clicked for me. The syntax just made sense while writing this
profile.

Unfortunately, it is a bit ugly but I think clarity is more important
and this syntax makes it very clear what components are related to the
subject and which ones relate to the peer.

I like Proposal 3 the best. I'd also be fine with dropping the '=' chars
from "peer=()" and "subj=()".

Proposal 3 seems to be the clear leader at this point. Speak up soon if
you're not a fan of Proposal 3.



As a side note, one thing that I'm not real happy about is the asymmetry
of send and receive rules.

When writing a send rule, it doesn't make sense to have a path,
interface, or member specified in the subject address grouping.

When writing a receive rule, it doesn't make sense to have a path,
interface, or member specified in the peer address grouping.

This is because you simply send a message through your connection, which
only consists of a connection name and a connection label. When you
receive, you receive messages according to the path, interface, and
member.

So, a rule like this wouldn't really translate to anything that made
sense:

  dbus bus=session subj=(path=/org/gnome/ScreenSaver interface=org.gnome.ScreenSaver) peer=(path=/com/canonical/indicator/session/session interface=com.canonical.indicator.session) (send receive),

But these two rules do makes sens:

  dbus bus=session subj=(path=/org/gnome/ScreenSaver interface=org.gnome.ScreenSaver) receive,
  dbus bus=session peer=(path=/com/canonical/indicator/session/session interface=com.canonical.indicator.session) send,

If we distill that down a little bit, it means that the only subj
conditionals that make sense with send are name and label and the only
peer conditionals that make sense with receive are name and label.

It seems like we should be able use that to come up with a syntax that
is simpler, but I haven't been able to think of one.

This isn't a blocker and we shouldn't spend much time on it, but if a
light bulb flipped on for anyone while reading that, I'd love to hear
their idea.

Tyler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20130611/1a62077d/attachment-0001.pgp>


More information about the AppArmor mailing list