[apparmor] DBus rule syntax for subject and peer components

[John Johansen]

On 06/12/2013 01:28 PM, Jamie Strandboge wrote:
> 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.
> 
yes where there is a specified component that makes the rule
ambiguous with respect to a none specified component we should
throw a semantic error