[apparmor] DBus rule syntax for subject and peer components

[Jamie Strandboge]

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
>>>> 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
> ambiguous.
> 
> 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...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20130612/86e6a38f/attachment.pgp>