[apparmor] dbus/pair address rule encoding

John Johansen john.johansen at canonical.com
Thu May 9 22:57:57 UTC 2013


On 05/09/2013 03:15 PM, Seth Arnold wrote:
> On Thu, May 09, 2013 at 03:08:35PM -0700, John Johansen wrote:
>> it depends how you look at it. To me it is changing the meaning of ->
>> of course I am now convinced that -> is just wrong and we need different
>> syntax, because -> just seems to have too many potential different
>> interpretations that could cause confusion
> 
> Or, we do a bit of jujitsu and -use- the meanings of -> as people seem
> to want to read it: do away with the word-based permissions.
> 
> Stick with me :)
> 
> dbus [address spec] acquire,   # unchanged
> dbus [address spec] -> [address spec], # unidirectional
> dbus [address spec] <- [address spec], # unidirectional
> dbus [address spec] <-> [address spec], # bidirectional
> 
> This does have a downside that identical rules could actually be written
> in two different ways:
> 
> dbus name=foo.org.sender -> ,
> dbus <- name=foo.org sender,
> 
> -or-
> 
> dbus -> name=foo.org.receiver,
> dbus name=foo.org.receiver <- ,
> 
> But if the arrows are so strongly tied to the direction information
> flows, we could just use it, and .. ignore the send and receive
> permissions entirely.
> 
> We'd want to keep the implicitly added "you get to receive replies to
> the messages you send", of course. That's just too useful to get rid of.
> 
tempting, you are right in that -> and perms cause a conflict, but

in the dbus case there is very much an asymmetry in the addressing,
more can we get rid of keyword perms entirely (acquire), and for
other forms of communication there are even more permissions
possible.




More information about the AppArmor mailing list