[apparmor] DBus rule syntax for subject and peer components

[Jamie Strandboge]

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?

-- 
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/20130611/3fca8966/attachment.pgp>