[apparmor] dbus/pair address rule encoding

[Tyler Hicks]

On 2013-05-09 13:35:11, John Johansen wrote:
> On 05/09/2013 01:20 PM, Jamie Strandboge wrote:
> > On 05/09/2013 02:41 PM, John Johansen wrote:
> >>
> >> Lets look at it as local (subject) address and remote/peer address
> >>
> >> profile subject {
> >>
> >>   dbus name=well.known.address acquire,
> >>
> >>   dbus name=well.known.address receive,  #subject can receive messages on this well.known.address
> >>
> >>   dbus -> name=a.peer.address send,      #subject can send to a peer/remote process using the well known address a.peer.address
> >>
> >>   dbus -> name=a.peer.address receive,   #subject can receive a message from a peer/remote process that sent from its a.peer.address
> >>                                          # this case is unusual
> >>
> >> }
> >>
> >> note that send atomically gives permission to receive a reply, just not to receive arbitrary new messages
> >>
> >> the unusually case is the one that tyler pointed out as problematic, and I'm not sure it really is but I would like to get this right
> >>
> > 
> > This explanation makes things a lot more clear for me. Part of my
> > problem was that I was trying to apply natural language to the rule, but
> > your explanation is clear.
> > 
> > That said, and speaking for myself only, I think I got tripped up
> > because '->' suggests a direction. In most cases this works out ok, but
> > in the unusual case:
> > dbus -> name=a.peer.address receive,
> > 
> > my brain was thinking that the '->' meant 'to' and therefore the subject
> > was sending something to the remote address, but the syntax actually
> > meant it was receiving something. We can document around this since it
> 
> yes natural language is the problem
> -> as to causes problems
> -> as my peer over there works
> 
> we debated word or symbols and nothing was great, but a symbol can be
> more universal and not get buried in the syntax
>   dbus name=foo.com peer name=foo.com iface=blah member=help,
> 
> peer just gets lost
> 
> > is the unusual case, but will this be so unusual with non-DBus rules
> > that use the same syntax? Would using 'remote:' be any clearer? Eg:
> >   dbus name=well.known.address acquire,
> >   dbus name=well.known.address receive,
> >   dbus remote: name=a.peer.address send,
> >   dbus remote: name=a.peer.address receive,
> > 
> it might, but again it seems to get lost like the peer example. There are
> trade offs I am not wedded to any one syntax
> 
> > Typing that out, it seems not because the specified access on the RHS of
> > the peer is actually describing (based on your descriptions, above) what
> > the subject can do, as opposed to what the peer can do, but my brain
> > wants the RHS of the peer to correspond to the peer itself, since it is
> > closer. I don't think there is a way to make that confusion go away by
> > substituting '->' for something else.
> > 
> nope it is specifying what the subject can do. It can send/receive from
> that remote.
> 
> The remote will have its own set of rules that specify what it can do.
> When communication happens BOTH set of rules are checked, and the communication
> is allowed only if BOTH allow it. That is neither subject dominates the other.
> 
> eg.
> 
> A {
>    ipc -> B (send, receive),
>    ipc -> C (send),
> }
> 
> B {
>    ipc -> A (send, receive),
>    ipc -> C (receive),
> }
> 
> C {
>   ipc -> A (send),
>   ipc -> B (send),
> }
> 
> A and B can talk freely
> 
> A and C can not communicate
> 
> B can receive messages from C
> 
> 
> > I'm tempted to suggest another syntax, but not sure how it would impact
> > the non-DBus applications of the syntax.
> > 
> please suggest away, its important to get this right (though we are trying
> to fit it in with existing syntax as best as possible).

I think that we're mostly ok. We just need to think about it a little
differently. Here's the current syntax:

DBUS RULE = [ 'audit' ] [ 'deny' ] 'dbus' [ DBUS BUS ] [ ( DBUS LOCAL CONDITIONS | -> DBUS REMOTE CONDITIONS ) ]  [ DBUS ACCESS EXPRESSION ]

Mentally, I've been making a strong connection between
<DBUS LOCAL CONDITIONS> and the application that we're confining. But
that's the wrong way to think about it. The arrow makes more sense if
you think about it in terms of traffic flow.


For example, to profile an application that acquires the well known name
com.example.service on the session bus and exports the ExampleMethod
method on the com.example.service interface, this would be what the dbus
portion of the service's profile looks like:

  dbus bus=session -> name=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus send,
  dbus bus=session name=com.example.service acquire,
  dbus bus=session -> name=com.example.service path=/com/example/service interface=com.example.service member=ExampleMethod receive,

Thie first rule allows the application to connect to the session bus.

The second rule allows the application to own the well known bus name
com.example.service.

The third rule allows messages to be sent from *any* connection to the
service. Note that the even though com.example.service is owned by the
application that we're profiling, it's address is specified in the
<DBUS REMOTE CONDITIONS>. I think that's acceptable.


If you wanted to confine an application that needs to call ExampleMethod, it's
profile would look like this:

  dbus bus=session -> name=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus send,
  dbus bus=session -> name=com.example.service path=/com/example/service interface=com.example.service member=ExampleMethod send,

The first rule allows the application to connect to the session bus.

The second rule allows the application to call the service's
ExampleMethod (the method_return permission is implied).

> 
> 
> 
> -- 
> AppArmor mailing list
> AppArmor at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20130509/c532bcbc/attachment.pgp>