[apparmor] DBus rule syntax for subject and peer components
jamie at canonical.com
Wed Jun 12 20:28:03 UTC 2013
On 06/12/2013 02:13 PM, Tyler Hicks wrote:
> 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
>>>> So, a rule like this wouldn't really translate to anything that made
>>>> 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
> of them.
> 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.
I'm inclined to agree with you, but want to here from others.
Jamie Strandboge http://www.ubuntu.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 899 bytes
Desc: OpenPGP digital signature
More information about the AppArmor