[apparmor] DBus rule syntax for subject and peer components

Wed Jun 12 20:43:21 UTC 2013

On 2013-06-12 11:40:18, Steve Beattie wrote:
> On Tue, Jun 11, 2013 at 02:41:03PM -0700, Tyler Hicks wrote:
> > > * 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,
> > > }
> 
> A dumb question due to my insufficient dbus knowledge: what
> is the difference between a path, an interface, and a dest? Because
> in your examples, you had rules with all three.

A dest (which will be changed to a name in the next syntax revision), is
the name of a connection. It may be a random name that the bus assigns
or it can be a well known name that the application requests. The
application may request multiple well known names (I think) and the
application can lose its well known name, in some situations, if another
process requests it. So, it is a little bit risky to specify a name in a
profile.

A path is a reference to an instance of an object. On the system bus,
accounts-daemon has an object for different users. So, it may have an
object referenced by path /org/freedesktop/Accounts/User1000 and another
referenced by path /org/freedesktop/Accounts/User1001.

An interface defines the object. It contains the members (methods and
signals).

I hope I didn't butcher that too badly. Here's the official docs:

http://dbus.freedesktop.org/doc/dbus-tutorial.html#concepts

> 
> > 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=()".
> 
> Is there a reason to go all 1970s creat() or should we spell out
> 'subject' entirely? I mean, other than using 'subj' makes rules line
> up in vertical columns nicely.

Heh, good point. Spelling out 'subject' is a good thing.

> 
> > 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.
> 
> Are there ever situations where one would write {send,receive} for
> the same set of paths/interfaces/dests, that isn't merely a case of
> being sloppy/lazy?

In another reply to this thread, I explained why combining send and
receive in a rule that contains paths/interfaces/dests is invalid and we
should avoid it.

> 
> You *could* make the argument that, since you would only ever specify
> a peer or a subj in a rule, you wouldn't need to specify either and
> the context would let you distinguish. My fear is that the implicit
> nature of whether you are referring to the subject's address or the
> peer's would be confusing to rule writers.

I agree that it would be confusing. It would also require too much
knowledge about what apparmor_parser is assuming for the general admin
that wants to take a look at a profile.

> 
> Also, something to keep in mind is that, while dbus uses what you
> might consider an anonymous endpoint for one end of each connection,
> other forms of IPC won't necessarily do so, e.g. networking. We'd
> ideally like to have a consistent language pattern across the IPC
> mechanisms we mediate, such that there's not too much cognitive
> dissonance when writing rules for multiple types of IPC.
> 
> So while I could kind of see reversing the permission and modifier
> ordering to be something like:
> 
>   dbus bus=session acquire dest=org.gnome.ScreenSaver,
>   dbus bus=session receive subj=(path=/org/gnome/ScreenSaver interface=org.gnome.ScreenSaver),
>   dbus bus=session send peer=(path=/com/canonical/indicator/session/session interface=com.canonical.indicator.session),
> 
> or even:
> 
>   dbus acquire bus=session dest=org.gnome.ScreenSaver,
>   dbus receive bus=session subj=(path=/org/gnome/ScreenSaver interface=org.gnome.ScreenSaver),
>   dbus send    bus=session peer=(path=/com/canonical/indicator/session/session interface=com.canonical.indicator.session),
> 
> would it make it too confusing for e.g.:
> 
>   # in this profile, allow ssh portforwarding via port 7979 on a tun
>   # device to the ssh port of a class rage of hosts
>   tcp send subj=(iface=tun* port=7979) peer=(addr=192.168.2.0/24 port=22),

I think this is still clear.

I am fine with:

dbus send bus=session ...,

I don't like the access coming after the bus:

dbus bus=session send ...,

Tyler

> 
> (I guess with this ordering I start to see why people have wanted
> to have the file permissions first before file paths, as the
> send/receive/acquire bits get lost visually, at least without syntax
> highlighting.)
> 
> Thanks for resurrecting the discussion with concrete examples.
> 
> -- 
> Steve Beattie
> <sbeattie at ubuntu.com>
> http://NxNW.org/~steve/

> -- 
> AppArmor mailing list
> AppArmor at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor

-------------- 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/20130612/8314e27b/attachment.pgp>