[apparmor] dbus/pair address rule encoding

[Tyler Hicks]

On 2013-05-09 15:08:35, John Johansen wrote:
> On 05/09/2013 02:59 PM, Tyler Hicks wrote:
> > On 2013-05-09 14:51:38, John Johansen wrote:
> >> On 05/09/2013 02:39 PM, Tyler Hicks wrote:
> >>> On 2013-05-09 14:30:32, John Johansen wrote:
> >>>> On 05/09/2013 02:13 PM, Tyler Hicks wrote:
> >>>>> On 2013-05-09 14:04:20, Seth Arnold wrote:
> >>>>>> On Thu, May 09, 2013 at 01:45:04PM -0700, Tyler Hicks wrote:
> >>>>>>> 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 ]
> >>>>>>>
> >>>>>>
> >>>>>> [ ... ]
> >>>>>>
> >>>>>>>
> >>>>>>> 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,
> >>>>>>>
> >>>>>>
> >>>>>> [ ... ]
> >>>>>>
> >>>>>>>
> >>>>>>> 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 the application acquired the interface and the application exports
> >>>>>> the method, why are those details placed on the 'peer' side of the
> >>>>>> arrow? I'm very confused here. :)
> >>>>>
> >>>>> I agree that if you think of it in terms of 'peer', it doesn't make
> >>>>> sense.
> >>>>>
> >>>>> For the arrow to make sense, we'd need to think of the right side of the
> >>>>> arrow as the destination of the message.
> >>>>>
> >>>>> Take this rule for example:
> >>>>>
> >>>>>   dbus bus=session -> name=com.example.service path=/com/example/service interface=com.example.service receive,
> >>>>>
> >>>>> If we adjust our thinking a little it could mean, "a message that flows
> >>>>> FROM anywhere TO com.example.service can be received under the
> >>>>> current profile."
> >>>>>
> >>>> maybe its just me, I see this as getting into the old to/from problem that netdomain had
> >>>
> >>> Mind explaining this a little more? I don't see netdomain in
> >>> apparmor.d(5) and have no idea what that problem may have been. :)
> >>>
> >> long ago there was a network extension to apparmor that did horrible
> >> things. It would make kernel devs cry and shake out of shear terror.
> >> It died on the vine because the hacks where unmaintainable, and
> >> would result in the kernel community hunting you down and killing you
> >> if you tried to submit it. :)
> >>
> >> Anyways its syntax tried to take a message flow approach with natural
> >> language and it ended up being confusing
> >>
> >> it went something like
> >>   tcp receive from blah,
> >>   tcp send to blah,
> >>
> >>   tcp send from blah to blah,
> >>   tcp send,receive from blah to blah,
> >>
> >> I don't remember the full syntax. But to/from would switch meaning based
> >> on whether send or receive was used and it had another problem I failing
> >> to remember.
> >>
> >> that is not to say your proposed syntax does this but it is flipping
> >> what I expect from -> and causing me to be confused.
> >>
> >> that is -> means one thing on send and other on receive
> > 
> > Funny, because I see the changes that I proposed making -> mean the same
> > thing always.
> > 
> 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

The change of ->'s meaning first clicked in my head when I was moving my
regression tests over to the -> notation. It just made sense to me all
of a sudden.

However, it isn't clicking for jdstrand or sarnold and you're now
convinced that -> is wrong. So, lets drop my proposed change of ->'s
meaning from the running and focus on something different (like
jdstrand's suggestion of moving the permissions closer to the subject).

Tyler

> 
> > I see it as meaning that if a message is flowing from the dbus connection
> > on the left to the dbus connection on the right, then here's the
> > permission that is allowed.
> > 
> > Yes, acquire is confusing if you think about it like that. :/
> > 
> :)
> 
> > 
> > Unfortunately, I think that we're always going to have the problem of
> > someone interpreting complex rules like this a little differently than
> > what someone else may interpret them. We'll just have to pick our poison
> > (but hopefully one that isn't too potent) and then be explicit in the
> > documentation.
> > 
> yep, I agree there people model/conceptualize things differently and
> a syntax that doesn't match what is expected is confusing. So we aren't
> going to please everyone
> 
> 
> 
> 
-------------- 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/2f25d7c5/attachment-0001.pgp>