[apparmor] DBus rule syntax for subject and peer components

[John Johansen]

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.