[apparmor] DBus rule syntax for subject and peer components
tyhicks at canonical.com
Wed Jun 12 19:13:13 UTC 2013
On 2013-06-11 23:30:58, John Johansen wrote:
> On 06/11/2013 03:04 PM, Jamie Strandboge wrote:
> > On 06/11/2013 04:41 PM, Tyler Hicks wrote:
> > ...
> >> 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.
> > I see what you are saying but we need all of subj with receive and all
> > of peer with send, so trying to come up with a syntax to accommodate
> > subj-only, peer-only and a reduced subj/peer seems rather complicated (I
> > couldn't come up with something else either). The parser is in a
> > position to warn/fail on subj/peer combinations that don't make sense
> > though-- maybe that is a reasonable compromise?
> so I agree that dealing with this asymmetry at the syntax level is the
> wrong place. It will needlessly complicate the syntax, and is the type
> of check that is handled by a semantic check.
I'm fine with that, but I'd like to be clear on what we will allow.
For "complex" rules, I'd like to propose that we require one and only
one access. No implied accesses, no combined accesses. By complex rules,
I'm talking about anything that includes a subj or peer conditional.
For example, this rule is ambiguous without an explicit access:
dbus bus=session subj=(path=/org/gnome/ScreenSaver interface=org.gnome.ScreenSaver),
and adding in a combined access also makes it ambiguous:
dbus bus=session subj=(path=/org/gnome/ScreenSaver interface=org.gnome.ScreenSaver) (send receive),
the only valid form of the rule is with the receive access:
dbus bus=session subj=(path=/org/gnome/ScreenSaver interface=org.gnome.ScreenSaver) receive,
Sure, there are conditionals that work with implied accesses:
dbus bus=session subj=(name=org.gnome.ScreenSaver),
but does that mean (send receive) or (send receive acquire)? It is still
That rule also makes sense with a combined acccess:
dbus bus=session subj=(name=org.gnome.ScreenSaver) (acquire receive),
But now documentation becomes convoluted because you have situations
where combined accesses work with some address conditionals but not all
So the only rules that could contain implied or combined accesses would
be rules in this basic form:
dbus [<bus>] [<access>],
What do you think? I think that it reduces complexity and makes policy
easier to read, at the expense of making policy a few lines longer.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: Digital signature
More information about the AppArmor